Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) |
Date | |
Msg-id | 5560.1564668481@sss.pgh.pa.us Whole thread Raw |
In response to | Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) (Shay Rojansky <roji@roji.org>) |
Responses |
Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.) |
List | pgsql-hackers |
Shay Rojansky <roji@roji.org> writes: >> I'm not sure we're any closer to a meeting of the minds on whether >> consulting zone[1970].tab is a good thing to do, but we got an actual >> user complaint[1] about how "localtime" should not be a preferred >> spelling. So I want to go ahead and insert the discussed anti-preference >> against "localtime" and "posixrules", as per 0001 below. If we do do >> something with zone[1970].tab, we'd still need these special rules, >> so I don't think this is blocking anything. > Just want to stress this point from a PostgreSQL driver maintainer > perspective (see here[1] for the full details). Having "localtime" as the > PostgreSQL timezone basically means that the timezone is completely opaque > from a client point of view - there is no way for clients to know what > actual timezone the server is in, and react to that. This is a limiting > factor in client development, I hope a consensus on this specific point can > be reached. I have in fact committed that patch. It won't do anything for your problem with respect to existing installations that may have picked "localtime", but it'll at least prevent new initdb runs from picking that. regards, tom lane Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [3754113f3] 2019-07-26 12:45:32 -0400 Branch: REL_12_STABLE [e31dfe99c] 2019-07-26 12:45:52 -0400 Branch: REL_11_STABLE [4459266bf] 2019-07-26 12:45:57 -0400 Branch: REL_10_STABLE [ae9b91be7] 2019-07-26 12:46:03 -0400 Branch: REL9_6_STABLE [51b47471f] 2019-07-26 12:46:10 -0400 Branch: REL9_5_STABLE [9ef811742] 2019-07-26 12:46:15 -0400 Branch: REL9_4_STABLE [6c4ffab76] 2019-07-26 12:46:20 -0400 Avoid choosing "localtime" or "posixrules" as TimeZone during initdb. Some platforms create a file named "localtime" in the system timezone directory, making it a copy or link to the active time zone file. If Postgres is built with --with-system-tzdata, initdb will see that file as an exact match to localtime(3)'s behavior, and it may decide that "localtime" is the most preferred spelling of the active zone. That's a very bad choice though, because it's neither informative, nor portable, nor stable if someone changes the system timezone setting. Extend the preference logic added by commit e3846a00c so that we will prefer any other zone file that matches localtime's behavior over "localtime". On the same logic, also discriminate against "posixrules", which is another not-really-a-zone file that is often present in the timezone directory. (Since we install "posixrules" but not "localtime", this change can affect the behavior of Postgres with or without --with-system-tzdata.) Note that this change doesn't prevent anyone from choosing these pseudo-zones if they really want to (i.e., by setting TZ for initdb, or modifying the timezone GUC later on). It just prevents initdb from preferring these zone names when there are multiple matches to localtime's behavior. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us
pgsql-hackers by date: