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
