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