From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David E. Wheeler" <david@justatheory.com>
cc: Peter Eisentraut <peter@eisentraut.org>,
        jian he <jian.universality@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Document DateStyle effect on jsonpath string()
In-reply-to: <E443FB23-3BEE-448D-95E4-F10904A10E5D@justatheory.com>
References: <56955B33-6959-4FDA-A459-F00363ECDFEE@justatheory.com> <CACJufxHREyTFzKOWz3f-yD14HxAdfeP1vGQQ2SQrusZ+ziRJyA@mail.gmail.com> <4D874C72-8939-4083-8336-AB114D9E29AD@justatheory.com> <CACJufxHE6q47-GEf3Kk0pD+Snr3yZMM4Byig2=bQKV8js7sP-A@mail.gmail.com> <B8E7081B-A8BE-4BAF-9C6B-AACD4F6EAB00@justatheory.com> <F492B399-37CB-471C-AEAD-25E1C19B607D@justatheory.com> <A556B643-F7E6-442D-9235-2D46A8A887C1@justatheory.com> <3541398.1725994308@sss.pgh.pa.us> <D6137AEA-0BE7-4328-9718-71B7E6BB4F6C@justatheory.com> <b847bc16-57b4-4701-870b-c4ed33d71e51@eisentraut.org> <3654686.1725999372@sss.pgh.pa.us> <5e8879d0-a3c8-4be2-950f-d83aa2af953a@eisentraut.org> <3811774.1726063865@sss.pgh.pa.us> <E443FB23-3BEE-448D-95E4-F10904A10E5D@justatheory.com>
Comments: In-reply-to "David E. Wheeler" <david@justatheory.com>
	message dated "Wed, 11 Sep 2024 11:00:09 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3824426.1726067484.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Sep 2024 11:11:24 -0400
Message-ID: <3824427.1726067484@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3824427.1726067484%40sss.pgh.pa.us>
Precedence: bulk

"David E. Wheeler" <david@justatheory.com> writes:
> I wonder, then, whether .string() should be modified to use the ISO form=
at in UTC, and therefore be immutable. That=E2=80=99s the format you get i=
f you omit .string() and let result be stringified from a date/time/timest=
amp.

What "let result be stringified" behavior are you thinking of,
exactly?  AFAICS there's not sensitivity to timezone unless you
use the _tz variant, otherwise it just regurgitates the input.

I agree that we should force ISO datestyle, but I'm not quite sure
about whether we're in the clear with timezone handling.  We already
had a bunch of specialized rules about timezone handling in the _tz
and not-_tz variants of these functions.  It seems to me that simply
forcing UTC would not be consistent with that pre-existing behavior.
However, I may not have absorbed enough caffeine yet.

			regards, tom lane