[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change
Brian.Inglis at SystematicSw.ab.ca
Fri Jan 26 18:33:45 UTC 2018
On 2018-01-26 06:54, Steve Summit wrote:
> Stephen Colebourne wrote:
>> Because applications have APIs that they want to continue to support
>> in a backwards compatible way. Even if everything were deprecated
>> today, those APIs would need to be supported for at least 10 years and
>> probably more.
> When and how forcefully to deprecate something really is one of
> the key questions here. But I think a big part of the disconnect
> is that, in many people's minds, the isdst-related portions of
> the TZ API have already been pretty severely deprecated for at
> least 10 years (maybe even 20).
Who has been deprecating which parts of the ABI/API where?
> So, quite aside from all the discussions over the specific
> Ireland case, it's worth asking: If the TZ project isn't already
> deprecating timezone and tm_isdst, should it be, and how
> strongly, and using what language in which documents?
> And what about POSIX? Is there any way of getting them to
> deprecate those inadequate old interfaces, and perhaps
> standardize tm_gmtoff while they're at it?
> Do we know how many programs are using timezone and tm_isdst
> (and the variable that says "this zone observes DST sometimes",
> and the other difficult API bits we've been discussing here)?
Github search result counts for some indications:
> Do we know why they think they have to use them? Is there
> guidance we can give them to help wean them off them?
Provide internationalized date and time interfaces that don't require changing
and reading struct tm fields to do complex date arithmetic, as in other
languages that support different calendars, concepts, units, and formats:
Julian to properly handle O.S. info, a few Islamic to handle Ramadan easily,
Chinese and Indian variations for those billions, Hebrew to handle those global
Internationalize tzdb so it can deal with other calendars mentioned and their
variations as easily as it can Gregorian, or switch the support base to a
language which can, and provide POSIX interfaces to a subset of the function,
non-POSIX interfaces for the rest.
Provide interfaces to handle different time scales easily: TAI, TT, UT1, JD/MJD,
NTP, GPS, Loran (aka right/), with or without leap seconds decided at run time;
and support time stamps down to at least the attosecond: in the 20th century,
folks used to get by with just ns, now clock_getres(3) is getting lower in the
ps; industries could be traded down to pennies in ns now; some Asian networks
are providing multi-GB/s home links; femtoseconds are used in production
engineering specs, but long run times may be required for accurate
characterizations; should the subsecond part use long long or long double?
Or don't and leave the existing interfaces alone?
Someone said time isn't easy: no kidding! ;^>
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
More information about the tz