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@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
