[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sun Jan 28 05:17:13 UTC 2018


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


More information about the tz mailing list