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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers