It turns out that some of the zone abbreviations shown in the IANA timezone database don't correspond to any real-world usage, but were more or less made up by the timezone database crew. And of late, those folk have started to remove these invented abbreviations in favor of just using numeric offsets. For example, part of the 2016f update did this:
# Asia/Novosibirsk covers: # 54 RU-NVS Novosibirsk Oblast +# From Stepan Golosunov (2016-05-30): +# http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1085784-6 +# moves Novosibirsk oblast from UTC+6 to UTC+7. +# From Stepan Golosunov (2016-07-04): +# The law was signed yesterday and published today on +# http://publication.pravo.gov.ru/Document/View/0001201607040064 + Zone Asia/Novosibirsk 5:31:40 - LMT 1919 Dec 14 6:00 - 6:00 - NOVT 1930 Jun 21 # Novosibirsk Time - 7:00 Russia NOV%sT 1991 Mar 31 2:00s - 6:00 Russia NOV%sT 1992 Jan 19 2:00s - 7:00 Russia NOV%sT 1993 May 23 # say Shanks & P. - 6:00 Russia NOV%sT 2011 Mar 27 2:00s - 7:00 - NOVT 2014 Oct 26 2:00s - 6:00 - NOVT + 6:00 - +06 1930 Jun 21 + 7:00 Russia +07/+08 1991 Mar 31 2:00s + 6:00 Russia +06/+07 1992 Jan 19 2:00s + 7:00 Russia +07/+08 1993 May 23 # say Shanks & P. + 6:00 Russia +06/+07 2011 Mar 27 2:00s + 7:00 - +07 2014 Oct 26 2:00s + 6:00 - +06 2016 Jul 24 2:00s + 7:00 - +07 According to the Russia rules, %s expands to nothing for standard time or "S" for summer time, so that the old entries here had the effect of defining NOVT and NOVST as meaning variously UTC+6, UTC+7, or UTC+8 at different times in the past. Now those abbreviations are gone, so far as IANA is concerned. I had thought that this wouldn't really affect us because PG's interpretations of zone abbreviations are driven by the info in timezone/tznames/ rather than the IANA files in timezone/data/. I forgot however that the "dynamic abbreviation" code relies on being able to find matching abbreviations in the IANA data. For example, timezone/tznames/Default lists NOVST Asia/Novosibirsk # Novosibirsk Summer Time (obsolete) but that zone abbreviation now fails entirely: # select '2016-09-02 08:00:00 NOVST'::timestamptz; ERROR: time zone abbreviation "novst" is not used in time zone "Asia/Novosibirsk" (This is also the cause of bug #14307.) So the question is what to do about it. An easy answer is to just delete such entries from the timezone/tznames/ files altogether. If we believe the IANA crew's assumption that nobody uses these abbreviations in the real world, then that seems like it removes useless maintenance overhead for little cost. I'm a little worried though that somebody might have followed IANA's lead and actually started using these abbreviations, in which case we'd get complaints. Another possibility is to keep these entries but get rid of the dynamic zone aliases, reducing them to plain numeric UTC offsets. Probably the value to use would be whatever was shown as the most recent active value in the IANA list ... although that's open to interpretation. For instance, according to the above we'd likely define NOVT as UTC+7, but then logically NOVST ought to be UTC+8, which doesn't match up with the fact that when it actually last appeared in the IANA data it meant UTC+7. So that sounds like it'd be a bit of a mess involving some judgment calls. In the end, part of the reason we've got these files is so that users can make their own decisions about abbreviation meanings. So the ultimate answer to any complaints is going to be "if you think NOVT means thus-and-such then put in an entry that says so". So I'm leaning to the just-remove-it answer for any deleted abbreviation that relies on a dynamic definition. Names that never had more than one UTC offset can remain in the tznames list. Comments? BTW, we should be glad that the IANA crew decided to use ISO not POSIX sign convention for these numeric zone abbreviations, or we'd really have a mess on our hands :-(. Also, the fact that this failure made it into releases shows that I'm missing some now-necessary validation steps in the zone data update procedure. Will add something about that to the timezone/README file. 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
