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@xxxxxxxxxxx