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

On Thu, Jun 27, 2019 at 1:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's not really clear to me that the IANA folk intend those files to
> be read as a list of preferred zone names.  If they do, what are we
> to make of the fact that no variant of "UTC" appears in them?

I think their intent is key.  We can't make reasonable decisions about
what to do with some data if we don't know what the data is intended
to mean.

> I think that predicting what IANA will do in the future is a fool's
> errand.  Our contract is to select some one of the aliases that the
> tzdb database presents, not to guess about whether it might present
> a different set in the future.  (Also note that a lot of the observed
> variation here has to do with whether individual platforms choose to
> install backward-compatibility zone names.  I think the odds that
> IANA proper will remove those links are near zero; TTBOMK they
> never have removed one yet.)

That doesn't make it a good idea to call Mountain time "Navajo," as
Andrew alleges we are doing.  Then again, the MacBook upon which I am
writing this email thinks that my time zone is "America/New_York,"
whereas I think it is "US/Eastern," which I suppose reinforces your
point about all of this being political. But on the third hand, if
somebody tells me that my time zone is America/New_York, I can say to
myself "oh, they mean Eastern time," whereas if they say that I'm on
"Navajo" time, I'm going to have to sit down with 'diff' and the
zoneinfo files to figure out what that actually means.

I note that https://github.com/eggert/tz/blob/master/backward seems
pretty clear about which things are backward compatibility aliases,
which seems to imply that we would not be taking a political position
separate from the upstream position if we tried to de-prioritize
those.

Also, https://github.com/eggert/tz/blob/master/theory.html says...

Names normally have the form
<var>AREA</var><code>/</code><var>LOCATION</var>, where
<var>AREA</var> is a continent or ocean, and
<var>LOCATION</var> is a specific location within the area.

...which seems to imply that AREA/LOCATION is the "normal" and thus
preferred form, and also that...

The file '<code>zone1970.tab</code>' lists geographical locations used
to name timezones.
It is intended to be an exhaustive list of names for geographic
regions as described above; this is a subset of the timezones in the data.

...which seems to support Andrew's idea that you can identify
AREA/LOCATION time zones by looking in that file.

Long story short, I agree with you that most people probably don't
care about this very much, but I also agree with Andrew that some of
the current choices we're making are pretty strange, and I'm not
convinced as you are that it's impossible to make a principled choice
between alternatives in all cases. The upstream data appears to
contain some information about intent; it's not just a jumble of
exactly-equally-preferred alternatives.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company