Thread
Commits
-
Doc: add info about timestamps with fractional-minute UTC offsets.
- fa4434810598 13.4 landed
- eda3b454a891 12.8 landed
- c1123be619fc 9.6.23 landed
- ab2e19987ff6 15.0 landed
- 94911ec28f01 14.0 landed
- 9034b6891279 10.18 landed
- 151d30e4ff4e 11.13 landed
-
Second-granular timezone offset format not documented
The Post Office <noreply@postgresql.org> — 2021-07-04T20:37:08Z
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/functions-formatting.html Description: I would like to request additional documentation on the timezone format that can be returned. Context: I had a problem with the HDBC-postgresql library, it cannot parse the second-granular timezone offsets returned by PostgreSQL. Here is an example of a format that I don't think the documentation currently covers: janus=> set timezone to 'America/Mexico_City'; SET janus=> select '1920-12-25' :: timestamptz; timestamptz ------------------------------ 1920-12-25 00:00:00-06:36:36 (1 row) Note how the response has a very weird timezone offset. I guess it is valid, but the documentation should note this as an edge case, since timezone offsets are typically only in minutes. Thank you for your patience. -
Re: Second-granular timezone offset format not documented
Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-05T01:05:19Z
PG Doc comments form <noreply@postgresql.org> writes: > Here is an example of a format that I don't think the documentation > currently covers: > janus=> set timezone to 'America/Mexico_City'; > SET > janus=> select '1920-12-25' :: timestamptz; > timestamptz > ------------------------------ > 1920-12-25 00:00:00-06:36:36 > (1 row) Yeah, fair point. There's a passing mention of fractional-minute offsets in Appendix B, but the main docs don't cover it at all. I propose the attached draft patch. regards, tom lane
-
Re: Second-granular timezone offset format not documented
Thomas Munro <thomas.munro@gmail.com> — 2021-07-05T06:12:30Z
On Mon, Jul 5, 2021 at 9:56 AM PG Doc comments form <noreply@postgresql.org> wrote: > Note how the response has a very weird timezone offset. I guess it is valid, As for whether it's valid, that's coming from the IANA tz dataset. It has a moment that it believes standard time to have begun at each location, in this case: Z America/Mexico_City -6:36:36 - LMT 1922 Ja 1 0:23:24 https://en.wikipedia.org/wiki/Time_in_Mexico#History seems to agree on the year at least. That "local mean time" offset is computed from the location's longitude, for lack of anything better. The tzinfo "Theory" file has a bunch of disclaimers about pre-1970 data though, including "the tz database's LMT offsets should not be considered meaningful".
-
Re: Second-granular timezone offset format not documented
Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-05T14:04:27Z
Thomas Munro <thomas.munro@gmail.com> writes: > As for whether it's valid, that's coming from the IANA tz dataset. It > has a moment that it believes standard time to have begun at each > location, in this case: > Z America/Mexico_City -6:36:36 - LMT 1922 Ja 1 0:23:24 > https://en.wikipedia.org/wiki/Time_in_Mexico#History seems to agree on > the year at least. That "local mean time" offset is computed from the > location's longitude, for lack of anything better. The tzinfo > "Theory" file has a bunch of disclaimers about pre-1970 data though, > including "the tz database's LMT offsets should not be considered > meaningful". I tried to interest them in dropping the LMT idea altogether [1]. Unsurprisingly, the proposal went nowhere. regards, tom lane [1] http://mm.icann.org/pipermail/tz/2021-May/030114.html
-
Re: Second-granular timezone offset format not documented
Thomas Munro <thomas.munro@gmail.com> — 2021-07-07T23:39:46Z
On Tue, Jul 6, 2021 at 2:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I tried to interest them in dropping the LMT idea altogether [1]. FWIW, I agree with you. It's meaningless because those coordinates don't seem to be the meridians historically used for local mean time (Trafalgar Square may be the prime meridian for pigeons, but real London time was based on its most famous observatory long before standardisation AFAICS, and if even that "zero case" is wrong, I guess the rest are wrong too where there even is an answer; the year given is also disputable). That's all fine and well given the disclaimer that it's meaningless, but then why even have it? The LMT concept is itself being applied proleptically (before the definition of mean time, before the existence of the named cities, ...). I think it would be a whole lot more useful and less surprising to make standard time proleptic instead, or just reject undefined conversions.