On 2018-01-27 19:22, Paul Eggert wrote:
Brian Inglis wrote:
NetBSD supports tzgetgmtoff(), tzgetname(), with tz and isdst parameters, since ~4.{2,3} according to ESR's doc.
Thanks, I'd forgotten about those NetBSD functions. However, they do not suffice for tzdata, since they assume at most two types of time can exist in a timezone_t object, something that is true for the simple POSIX model but is false for tzdb. So code should not use these functions if it wants to work on arbitrary timestamps. This is why I didn't add these functions to tzcode when I added support for tzalloc, tzfree, etc.
Also, even if one assumes POSIX, tzgetgmtoff and tzgetname are not much use on platforms like NetBSD that have tm_gmtoff and tm_zone.
They are probably of advantage mainly to insulate developers porting apps supporting tz, whether or not their library or OS has struct tm or globals extensions. I appreciate the orthogonal architectural simplicity of BSD extensions supporting time from the machine to the application layers - [get][s][bin,nano,micro][up]time() etc.: that would be a nice API to add to standards, as would extensions to that API for DJB's libtai with attosecond precision, and similar type extensions to the rest of the standard API, perhaps using some mechanisms for type generic math to support type generic time. I am cautiously positive about future improvements in C, with its C11 addition of TIME_UTC and timespec_get(), implying other time bases, epochs, scales, or coordinates could be added by implementations, and to a future standard. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada