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

From Tom Lane
Subject Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date
Msg-id 13181.1562082452@sss.pgh.pa.us
Whole thread Raw
In response to Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

I agree that if there were an easy way to discount the IANA "backward
compatibility" zone names, that'd likely be a reasonable thing to do.
The problem is that those names aren't distinguished from others in
the representation we have available to us (ie, the actual
/usr/share/zoneinfo file tree).  I'm dubious that relying on
zone[1970].tab would improve matters substantially; it would fix
some cases, but I don't think it would fix all of them.  Resolving
all ambiguous zone-name choices is not the charter of those files.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TopoSort() fix
Next
From: Alexey Kondratov
Date:
Subject: Re: Conflict handling for COPY FROM