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

[Michael H Deckers]

     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!

     Michael Deckers.