From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Document DateStyle effect on jsonpath string() |
Date: | 2024-09-11 15:11:24 |
Message-ID: | 3824427.1726067484@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David E. Wheeler" <david(at)justatheory(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-09-11 15:19:59 | Re: Detailed release notes |
Previous Message | Andrew Dunstan | 2024-09-11 15:04:55 | Re: Jargon and acronyms on this mailing list |