[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change
Michael H Deckers
michael.h.deckers at googlemail.com
Fri Jan 26 21:39:26 UTC 2018
On 2018-01-24 18:36, Stephen Colebourne wrote:
>> Want to make things truly better? Agree to move TZDB under the
>> auspices of CLDR, so it can be managed by a paid team who actually
>> understand stability and compatibility, and the trade off of those
>> against some abstract notion of purity. As a combined dataset, there
>> would be the ability to solve the text problem in a realistic and
>> pragmatic way.
I disagree. I have observed tzdb since more than 20 years and it has
always been a treasure trove of carefully researched information on
historical time scales. You may call "abstract purity" what I
perceive as historical accuracy -- but I believe it is useful
to clearly present such historical information to the (many)
diverse computer interfaces that need such data, without
showing noise without such corroboration. Many recent changes
effected under the lead of Paul Eggert have clarified the
scope and the limits of the tz data.
As an example for the advantage of such separation consider
the issue of naming time zone timescales. tzdb has decided
not to deal with this issue; its careful research would
involve local and political issues beyond the scope of the
tzdb project. On the other hand, the CLDR project is well
suited to tackle this issue, but only for the presently
used time scales.
>> TZDB is not the centre of the universe. It is a small cog in a much
>> bigger machine. It's time to accept that.
The issue at hand is the recently (2018a) proposed change to
Europe/Dublin which changes the dst bit when UTC >= 1971-10-31 + 02 h.
This change in fact contradicts the assertion which has been
made continually by tzdb in newctime.3 since at least
1993-01-08 (for 25 years), that
"Tm_isdst is non-zero if summer time is in effect.",
and several other assertions to the same effect throughout tzdb.
There is also the claim that tm_isdst is a "vestigial" interface
for which a change hindering customers in any way should
obviously be avoided. I therefore think it is only fair that tzdb
has suspended the proposed change. After all, it is tzdb that is
proposed to change their documented interface, not the users of tzdb.
Before this change proceeds, it is, in my opinion, necessary
to obtain agreement on what the new significant (non-vestigial)
role of the dst bit, if any, should be in the future (beyond the
single case of Ireland). Of course, the change, if any, must be
documented clearly in decent time before it is implemented, so
that an upgrade path can be designed by all users.
I doubt that all this would ever happen if tzdb was a part of CLDR!
More information about the tz