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.