Hearing no further comments on this, I adjusted DecodeTimeOnly to
look more like DecodeDateTime as I recommended upthread, and pushed.
regards, tom lane
Alexander Lakhin writes:
> I also wonder how the units affect time zone parsing.
> With the patch:
> SELECT time with time zone '010203m+3';
> ERROR: invalid input syntax for type time with time zone: "010203m+3"
> But without the patch:
> SELECT time with time zone '010203m+3';
> 01:02:03+03
On 04.03.23 22:05, Tom Lane wrote:
Joseph Koshakow writes:
On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow wrote:
I just found another class of this bug that the submitted patch does
not fix. If the units are at the beginning of the string, then they are
also ignored. For example, `date 'm
10.03.2023 03:26, Tom Lane wrote:
Joseph Koshakow writes:
Also I removed some dead code from the previous patch.
That's a little weird, or maybe even a lot weird, but it's not
inherently nonsensical so I'm hesitant to stop accepting it.
However, if UNITS acts that way, then why is ISOTIME
Joseph Koshakow writes:
> Also I removed some dead code from the previous patch.
This needs a rebase over bcc704b52, so I did that and made a
couple of other adjustments.
I'm inclined to think that you removed too much from DecodeTimeOnly.
That does accept date specs (at least for timetz), and
Also I removed some dead code from the previous patch.
- Joe Koshakow
From 2ff08d729bca87992514d0651fdb62455e43cd8a Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 10 Dec 2022 18:59:26 -0500
Subject: [PATCH] Remove unknown ISO format, handle dandling units
This commit removes the date
On Sun, Mar 5, 2023 at 12:54 PM Tom Lane wrote:
>
> We do accept this:
>
> => select '12:34'::time;
>time
> --
> 12:34:00
> (1 row)
>
> so that must be going through a different code path, which I didn't
> try to identify yet.
That query will contain a single field of "12:34" with
[ I removed Lockhart, because he's taken no part in Postgres work for
more than twenty years; if that address even still works, you're
just bugging him ]
Alexander Lakhin writes:
> In fact,
> SELECT time 'h04mm05s06';
> doesn't work for many years, but
> SELECT time 'h04mm05s06.0';
> still
Attached is a patch for removing the discussed format of date-times.
From f35284762c02ed466496e4e562b5f95a884b5ef1 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 10 Dec 2022 18:59:26 -0500
Subject: [PATCH] Remove unknown ISO format, handle dandling units
This commit removes the date
Hello,
05.03.2023 02:31, Joseph Koshakow wrote:
I also don't have a copy of ISO 8601 and wasn't able to find anything
about this variant on Google. I did find this comment in datetime.c
/*
* Was this an "ISO date" with embedded field labels? An
* example is "y2001m02d04" - thomas 2001-02-04
*/
On Sat, Mar 4, 2023 at 4:05 PM Tom Lane wrote:
>
>I started to look at this, and soon noticed that while we have test
cases
>matching this sort of date input, there is no documentation for it.
The
>code claims it's an "ISO" (presumably ISO 8601) format, and maybe it is
>because it
Joseph Koshakow writes:
> On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow wrote:
>> I just found another class of this bug that the submitted patch does
>> not fix. If the units are at the beginning of the string, then they are
>> also ignored. For example, `date 'm d y2020m11d3'` is also
On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow wrote:
>
> I just found another class of this bug that the submitted patch does
> not fix. If the units are at the beginning of the string, then they are
> also ignored. For example, `date 'm d y2020m11d3'` is also valid. I
> think the fix here is
I just found another class of this bug that the submitted patch does
not fix. If the units are at the beginning of the string, then they are
also ignored. For example, `date 'm d y2020m11d3'` is also valid. I
think the fix here is to check and make sure that ptype is 0 before
reassigning the value
On Sun, Dec 11, 2022 at 10:29 AM Joseph Koshakow wrote:
>
> Hi all,
>
> Attached is a patch to fix a parsing error for date-time types that
> allow dangling units in the input. For example,
> `date '1995-08-06 m y d'` was considered a valid date and the dangling
> units were ignored.
>
>
Hi all,
Attached is a patch to fix a parsing error for date-time types that
allow dangling units in the input. For example,
`date '1995-08-06 m y d'` was considered a valid date and the dangling
units were ignored.
Intervals also suffer from a similar issue, but the attached patch
doesn't fix
16 matches
Mail list logo
