Re: Second-granular timezone offset format not documented

2021-07-07 Thread Thomas Munro
On Tue, Jul 6, 2021 at 2:04 AM Tom Lane 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 f

Re: Second-granular timezone offset format not documented

2021-07-05 Thread Tom Lane
Thomas Munro 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#Histor

Re: Second-granular timezone offset format not documented

2021-07-04 Thread Thomas Munro
On Mon, Jul 5, 2021 at 9:56 AM PG Doc comments form 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

Re: Second-granular timezone offset format not documented

2021-07-04 Thread Tom Lane
PG Doc comments form 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-2

Second-granular timezone offset format not documented

2021-07-04 Thread PG Doc comments form
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 libra