Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.)
Дата
Msg-id 20190606171850.ilssehzrvrrfuiqs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-06-06 12:51:30 -0400, Tom Lane wrote:
> [ sorry for slow response, I'm on vacation ]

Good.


> Andres Freund <andres@anarazel.de> writes:
> > That makes sense. As far as I can tell the reason that 12 sometimes ends
> > up with the proper timezone is that we shortcut the search by:
>
> >     /*
> >      * Try to avoid the brute-force search by seeing if we can recognize the
> >      * system's timezone setting directly.
> >      *
> >      * Currently we just check /etc/localtime; there are other conventions for
> >      * this, but that seems to be the only one used on enough platforms to be
> >      * worth troubling over.
> >      */
> >     if (check_system_link_file("/etc/localtime", &tt, resultbuf))
> >         return resultbuf;
>
> > which is actually a behaviour changing, rather than just an
> > optimization, when there's a lot of equivalently scoring timezones.
>
> Sure, that is intentionally a behavior change in this situation.
> The theory is that if "Etc/UCT" is what the user put in /etc/localtime,
> then that's the spelling she wants.  See 23bd3cec6.

Right, I'm not complaining about that. I'm just noting that that
explains the cross-version divergence.

Note that on 11 I *do* end up with some *other* timezone with the newer
timezone data:

$cat /etc/timezone;ls -l /etc/localtime
Etc/UTC
lrwxrwxrwx 1 root root 27 Jun  6 17:02 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC

$ rm -rf /tmp/tztest;~/build/postgres/11-assert/install/bin/initdb /tmp/tztest 2>&1|grep -v 'scores 0'|grep -v 'uses
leapseconds';grep timezone /tmp/tztest/postgresql.conf
 
...
TZ "Zulu" gets max score 5200
TZ "UCT" gets max score 5200
TZ "Universal" gets max score 5200
TZ "UTC" gets max score 5200
TZ "Etc/Zulu" gets max score 5200
TZ "Etc/UCT" gets max score 5200
TZ "Etc/Universal" gets max score 5200
TZ "Etc/UTC" gets max score 5200
TZ "localtime" gets max score 5200
TZ "posix/Zulu" gets max score 5200
TZ "posix/UCT" gets max score 5200
TZ "posix/Universal" gets max score 5200
TZ "posix/UTC" gets max score 5200
TZ "posix/Etc/Zulu" gets max score 5200
TZ "posix/Etc/UCT" gets max score 5200
TZ "posix/Etc/Universal" gets max score 5200
TZ "posix/Etc/UTC" gets max score 5200
ok
...

log_timezone = 'UCT'
timezone = 'UCT'
#timezone_abbreviations = 'Default'     # Select the set of available time zone
                    # share/timezonesets/.

As you can see the switch from Etc/UTC to UCT does happen here
(presumably in any branch before 12). Which did not happen before the
import of 2019a / when using a system tzdata that's before
that. There you get:

TZ "Zulu" gets max score 5200
TZ "Universal" gets max score 5200
TZ "UTC" gets max score 5200
TZ "Etc/Zulu" gets max score 5200
TZ "Etc/Universal" gets max score 5200
TZ "Etc/UTC" gets max score 5200
ok

and end up with UTC as the selection.

I do think that < 12 clearly regressed here, although it's only exposing
previous behaviour further.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashwin Agrawal
Дата:
Сообщение: Re: Removing a few more lseek() calls
Следующее
От: Alvaro Herrera
Дата:
Сообщение: LLVM compile failing in seawasp