Date: Mon, 12 Feb 2018 08:26:25 +0000 From: Stephen Colebourne <scolebourne@joda.org> Message-ID: <CACzrW9CyxYAv+=F8X=rmU9E3Cd+ZbgLvNF3LxjNagfi4tfeg-Q@mail.gmail.com> I typed this reply on Tuesday, then decided to defer sending it, hoping that someone else might refute some of the nonsense that was in this message. The rest of this e-mail is untouched from then (now that Paul has replied, the similarities in the parts we both mention are meaningful I think.) kre | In addition, every user of these libraries has gone to IANA for the | files for over 15 years - they understand IANA to be the source of | timezone data. Breaking that is undesirable. Nonsense. First because IANA was not involved in any way at all until (I think) mid (or late) 2012 (perhaps even 2013) - which is something less than 15 years ago ... going to IANA for this data before then would have been a colossal waste of time. Second, the vast majority of users of this data get it from their system vendor (via MacOS, Android, whichever Linux or BSD they're using, etc - Windows users, as I understand it, are even more isolated though the primary data ends up there too). None of those bother IANA at all (other than the few, like those on this list, who have a greater than normal interest.) For the people who make those distributions, getting the data from IANA is entirely reasonable - for end users it is not. IANA is not funded to provide that level of service, and it was never part of our agreement with them (via the IESG) to provide that level of access. If it gets abused, they're quite likely to simply say "we're done" and delete the whole thing - if you have (or anyone has) users depending upon it, they would suffer, and there's nothing you could do about it (they would not even have to give any advance notice, though they probably would.) | The only visible change for zic is a flag that is | deprecated/discouraged. In the zic output, and currentl.y - but the source data should be correct, deliberately supplying lies just so some software doesn't break (over the long term) is intolerable. | We have had an agreement for many years that the zic input files | represent an API used by other systems, Where exact;ly was that agreement created / docuumented? We have known that people have other translators of the zic input data format, but it has always been understood, I believe, and generally implemented, that when the format changed it was their responsibility to update to handle it (ie: that is what actually has happened). |. While everyone accepts that the importance of positive SAVE | values was not previously established, it clearly is now. I disagree. there is some broken software that is making a bogus assumption. That needs to be fixed. There is no fundamental reason why the SAVE value needs to be positive (or non-negative to allow for the pedantry in someone else's message), it isn't even difficult to deal with all possibilities - it just needs to be done. And no-one, anywhere, should be assuming that the zic input format is fixed, it isn't, and never has been. It has changed several times, and will do again I have little doubt. If you had been taking any notice of what has been happening over the past 15 years (or better, back for the 30+ years this project has existed) you'd know that. kre