On 2021-05-22 12:09:23 +0200, Peter J. Holzer wrote: > On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: > > On 5/18/21 11:31 PM, Bryn Llewellyn wrote: > > > This seems to be at odds with what section “8.5.3. Time Zones” at > > > > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES <https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES> > > > > > > says: > > > > > > « > > > A time zone abbreviation, for example PST. Such a specification merely > > > defines a particular offset from UTC, in contrast to full time zone > > > names which can imply a set of daylight savings transition rules as > > > well. The recognized abbreviations are listed in > > > the pg_timezone_abbrevs view (see Section 51.91). You cannot set the > > > configuration parameters TimeZone or log_timezone to a time zone > > > abbreviation, but you can use abbreviations in date/time input values > > > and with the AT TIME ZONE operator. > > > » > > > > > > This claims (as I read it) that a time zone abbreviation uniquely > > > determines an offset from UTC. > > > > It says no such thing > > Maybe that's the inherent ambiguity of the English language, but to me > "Such a specification defines a particular offset from UTC" does imply a > one-to-one mapping from abbreviation to offset. And I just realised that "one-to-one" isn't the right term. Mathematically it would be "functional": There is exactly one offset for each abbreviation (never two or more; there might be zero but in that case one could argue that this isn't actually a time zone abbreviation), but several abbreviations can map to the same offset. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@xxxxxx | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!"
Attachment:
signature.asc
Description: PGP signature
