Second-granular timezone offset format not documented
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.
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
Attachments:
doc-fractional-minute-offsets.patchtext/x-diff; charset=us-ascii; name=doc-fractional-minute-offsets.patchDownload+38-8
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".
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]http://mm.icann.org/pipermail/tz/2021-May/030114.html.
Unsurprisingly, the proposal went nowhere.
regards, tom lane
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.