Re: The contents of the pg_timezone_names view bring some surprises - Mailing list pgsql-general

From Adrian Klaver
Subject Re: The contents of the pg_timezone_names view bring some surprises
Date
Msg-id 47bb220f-23d4-f100-b3b0-ecf4a4f7a110@aklaver.com
Whole thread Raw
In response to Re: The contents of the pg_timezone_names view bring some surprises  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: The contents of the pg_timezone_names view bring some surprises  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
List pgsql-general
On 5/22/21 3:09 AM, 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.

As your later post points out the reality is a given abbreviation has 
only one offset, but an offset may have many abbreviations.

> 
>> and would be lying if it did.
> 
> As far as pg_timezone_abbrevs is concerned, it is correct. abbrev is
> unique in that view:

1) Go to Postgres cluster and in ~/share/timezonesets search in 
Defaults.txt for the word C(c)onflict.

2)Then go here 
https://www.postgresql.org/docs/current/datetime-config-files.html and 
see how the below query could be made to change if someone is not aware 
of 1).

More below.
> 
> hjp=> select abbrev, count(*) from pg_timezone_abbrevs group by 1 having count(*) > 1;
> ╔════════╤═══════╗
> ║ abbrev │ count ║
> ╟────────┼───────╢
> ╚════════╧═══════╝
> (0 rows)
> 
> (at least in PostgreSQL 11.12)
> 
> It is not true in "the real world", where different time zones may use
> the same abbreviation. But that isn't what the paragraph is about.

~/share/timezonesets encompasses the 'real world'.

> 
> 
>> What it is saying that, for example,  the timezone America/Los_Angeles has
>> two timezone abbreviations PDT(what I'm currently in) and PST. If you use an
>> abbreviation you don't get the DST transition rules that a full timezone
>> name has.
> 
> Yes, does also say that.
> 
>          hp
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: PG 14 - can't upgrade from a database using an aggregate with anyelement and anyarray
Next
From: "Peter J. Holzer"
Date:
Subject: Re: The contents of the pg_timezone_names view bring some surprises