I wrote:
> The urgency of updating our timezone code has risen quite a bit for me,
> because while testing an update of the data files to tzdata2014h I became
> aware that the "-P" option is failing to print a noticeable number of
> zone abbreviations that clearly exist in the data files. Since the -P
> hack itself is so simple, it's hard to come to any other conclusion than
> that the rest of the timezone code is buggy --- presumably because it's
> four years behind what IANA is targeting with the data files.
Ah, scratch that. On further investigation, it turns out that my code for
"-P" is in fact wrong; it misses out printing zone abbreviations in cases
where an area reverted to an older meaning of a zone abbrev after having
used another meaning for awhile. Which, in fact, is what the Russians
have just done, and it seems it's happened rather often elsewhere as well.
We do still need to work on syncing our code with IANA's updates one way
or the other, because eventually they are going to start shipping zone
definitions that break older copies of the library; this has been
mentioned more than once on the IANA announcement list. But it doesn't
seem like that has happened quite yet.
Meanwhile, it looks like there's a fair amount of missed updates in our
tznames/ files as a result of this error. Off I go to look at that.
(The underlying motivation here is that I'd like to get the tzdata2014h
updates installed before we wrap 9.4beta3. Since it looks like those
changes are going to be rather invasive, it seems like getting some beta
testing on them would be a good thing before we unleash them on
back-branch releases.)
regards, tom lane
