Robert Haas writes:
> I suggest that if you (or someone else who understands it, if there is
> any such person) were willing to either improve the existing
> documentation or maybe even write a whole new chapter on how we do
> time zone handling, it would be most welcome.
Well, I'll put that on m
On Fri, Sep 2, 2016 at 8:55 AM, Tom Lane wrote:
> 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" co
I wrote:
> So the idea I'm toying with (again, haven't tried to code this) is to say
> that *if* we can match the abbreviation to something in the referenced
> zone then we'll use that, but otherwise we fall back to treating the
> abbreviation as a macro for the zone name.
This turned out to requi
I wrote:
> 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.
After a bit more thought and consumption of caffeine, I am thinking that
that won't really be
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 off
