[tz] [PROPOSED] Support zi parsers that mishandle negative DST offsets
kre at munnari.OZ.AU
Thu Feb 15 14:46:24 UTC 2018
Date: Mon, 12 Feb 2018 08:26:25 +0000
From: Stephen Colebourne <scolebourne at joda.org>
Message-ID: <CACzrW9CyxYAv+=F8X=rmU9E3Cd+ZbgLvNF3LxjNagfi4tfeg-Q at 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.)
| 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
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
More information about the tz