public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tom Lane <[email protected]>
To: David E. Wheeler <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Inconsistent Parsing of Offsets with Seconds
Date: Sat, 22 Jun 2024 13:15:59 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

"David E. Wheeler" <[email protected]> writes:
> The treatment of timestamptz (and timetz) values with offsets that include seconds seems a bit inconsistent.

It's hard to get excited about this.  Per the IANA TZ data,
nowhere in the world has used fractional-minute UT offsets
since 1972:

# In 1972 Liberia was the last country to switch from a UT offset
# that was not a multiple of 15 or 20 minutes.

and they were twenty years later than the next-to-last place (although
IANA will steadfastly deny reliability for their TZ data before 1970).
So timestamps like this simply don't exist in the wild.

> The corresponding jsonpath methods don’t like offsets with seconds *at all*:

Perhaps that should be fixed, but it's pretty low-priority IMO.
I doubt there is any standard saying that JSON timestamps need
to be able to include that.

> I see from the source[1] that offsets between plus or minus 15:59:59
> are allowed; should the `OF` and `TZ formats be able to parse them?

I'd vote no.  to_date/to_char already have enough trouble with format
strings being squishier than one might expect.

			regards, tom lane






view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Inconsistent Parsing of Offsets with Seconds
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox