On 5/19/21 5:50 PM, Bryn Llewellyn wrote:
> Thanks, as ever, David and Tom, for your quick responses. Thanks also to
> Adrian Klaver, who replied in a branched thread with this—in response to
> my comment about my reading of the information content of the
> pg_timezone_abbrevs view: « This claims (as I read it) that a time zone
> abbreviation uniquely determines an offset from UTC. »
>
>
> *Secondly, Adrians's response.*
>
> Yes, the point that a timezone abbreviation does not uniquely determine
> the timezone offset is taken now. But notice this:
>
> « In short, this is the difference between abbreviations and full names:
> abbreviations represent a specific offset from UTC…»
> from
>
> "8.5.3. Time Zones"
> https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES
> <https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES>
>
> This seems to me to be flat-out wrong. An abbreviation, in general, does
> not represent a specific offset from UTC. Rather, it can represent two
> or more different offsets.
It is not flat out wrong. An abbreviation, say the one I'm in now PDT,
will only represent a specific offset(-07), whereas the timezone I'm in,
America/Los_Angeles, represents two offsets(-08/-07) the value of which
depends on the date. Now there maybe another abbreviation that uses that
same offset, but again it only represents a single offset.
> Nonsense, eh? As David said, it's an instance of the more general:
>
> set timezone = 'Foo42Bar';
> show timezone;
>
> I wish there was a way to turn this off and accept only
> pg_timestamp_names.name values.
>
> The second reason is that the abbreviations confuse ordinary readers who
> are slow to remember the "up is down" story.
>
The issue is you are looking for logic in a system that is based on
political decisions. For instance there is a brewing West Coast
movement, whereby the states on the US West Coast are looking to drop
the DST transition with or without the approval of Congress. COVID
stalled it, but I expect it will appear again in the near future.
--
Adrian Klaver
adrian.klaver@aklaver.com
