From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inconsistent Parsing of Offsets with Seconds |
Date: | 2024-06-24 12:08:14 |
Message-ID: | 5AF1E7E9-5856-4BE2-B691-3E41A0A903F5@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 22, 2024, at 14:10, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> I believe the former issue is caused by the latter: The jsonpath implementation uses the formatting strings to parse the timestamps[1], and since there is no formatting to support offsets with seconds, it doesn’t work at all in JSON timestamp parsing.
>
> [1]: https://github.com/postgres/postgres/blob/70a845c/src/backend/utils/adt/jsonpath_exec.c#L2420-L2442
A side-effect of this implementation of date/time parsing using the to_char templates is that only time zone offsets and abbreviations are supported. I find the behavior a little surprising TBH:
david=# select to_timestamp('2024-06-03 12:35:00America/New_York', 'YYYY-MM-DD HH24:MI:SSTZ');
ERROR: invalid value "America/New_York" for "TZ"
DETAIL: Time zone abbreviation is not recognized.
Unless the SQL standard only supports offsets and abbreviations, I wonder if we’d be better off updating the above parsing code to also try the various date/time input functions, as well as the custom formats that *are* defined by the standard.
Best,
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2024-06-24 12:16:28 | Re: Changing default -march landscape |
Previous Message | Amit Kapila | 2024-06-24 11:50:21 | Re: speed up a logical replica setup |