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

[Brian Inglis]

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:

[tm_isdst fork:true]

Repositories
Code	12K
Commits	38K
Issues	679
Topics
Wikis	22
Users

[tm_gmtoff fork:true]

Repositories
Code	1K
Commits	11K
Issues	224
Topics
Wikis
Users

[tm_zone fork:true]

Repositories	3
Code	846
Commits	13K
Issues	132
Topics
Wikis	2
Users

[timezone fork:true]

Repositories	6K
Code	103K
Commits	1M
Issues	114K
Topics	35
Wikis	13K
Users	27

Languages
    2,046 JavaScript
    654 Ruby
    648 Python
    520 PHP
    302 Java
    268 Swift
    144 HTML
    124 C++
    111 CSS
    102 Shell

> 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
communities.

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