Horton

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-26T00:18:47Z
Lists: pgsql-hackers 
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> I was planning on submitting a follow-up myself (for pg13+) for
> discussion of further improvements. My suggestion would be that we
> should have the following order of preference, from highest to lowest:

>  - UTC  (justified by being an international standard)
>  - Etc/UTC
>  - zones in zone.tab/zone1970.tab:
>      These are the zone names that are intended to be presented to the
>      user to select from. Dispute the exact meaning as you will, but I
>      think it makes sense that these names should be chosen over
>      equivalently good matches just on that basis.
>  - zones in Africa/ America/ Antarctica/ Asia/ Atlantic/ Australia/
>    Europe/ Indian/ Pacific/ Arctic/
>      These subdirs are the ones generated by the "primary" zone data
>      files, including both Zone and Link statements but not counting
>      the "backward" and "etcetera" files.
>  - GMT  (justified on the basis of its presence as a default in the code)
>  - Etc/*
>  - any other zone name with a /
>  - any zone name without a /, excluding 'localtime' and 'Factory'
>  - 'localtime'
>  - 'Factory'

TBH, I find this borderline insane: it's taking a problem we did not
have and moving the goalposts to the next county.  Not just any
old county, either, but one where there's a shooting war going on.

As soon as you do something like putting detailed preferences into the
zone name selection rules, you are going to be up against problems like
"should Europe/ have priority over Asia/, or vice versa?"  This is not
academic; see for example

Link	Asia/Nicosia	Europe/Nicosia
Link	Europe/Istanbul	Asia/Istanbul	# Istanbul is in both continents.

These choices affect exactly the people who are going to get bent out of
shape because you picked the "wrong" name for their zone.  Doesn't matter
that both names are "wrong" to different subsets.

As long as we have a trivial and obviously apolitical rule like
alphabetical order, I think we can skate over such things; but the minute
we have any sort of human choices involved there, we're going to be
getting politically driven requests to do-it-like-this-because-I-think-
the-default-should-be-that.  Again, trawl the tzdb list archives for
awhile if you think this might not be a problem:
http://mm.icann.org/pipermail/tz/

I think we can get away with fixing simple cases that are directly
caused by tzdb's own idiosyncrasies, ie "localtime" and "posixrules"
and "Factory".  If we go further than that, we *will* regret it.

			regards, tom lane

Commits

  1. Tweak our special-case logic for the IANA "Factory" timezone.

  2. Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

  3. Prefer timezone name "UTC" over alternative spellings.

  4. Attempt to identify system timezone by reading /etc/localtime symlink.

  5. Update time zone data files to tzdata release 2019a.