Re: Document DateStyle effect on jsonpath string()
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2024-09-11T15:11:24Z
Lists: pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes: > I wonder, then, whether .string() should be modified to use the ISO format in UTC, and therefore be immutable. That’s the format you get if you omit .string() and let result be stringified from a date/time/timestamp. 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
Commits
-
Make jsonpath .string() be immutable for datetimes.
- cc4fdfa411fa 17.0 landed
- cb599b9ddfcc 18.0 landed
-
Improve documentation and testing of jsonpath string() for datetimes.
- ed055d249df5 18.0 landed