On 04.03.23 22:05, Tom Lane wrote:
> Joseph Koshakow<koshy44@gmail.com> writes:
>> On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow<koshy44@gmail.com> 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 to check and make sure that ptype is 0 before
>>> reassigning the value to a non-zero number. I'll send an updated patch
>>> with this tonight.
>> Attached is the described patch.
> 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 looks a lot like the ISO 8601 format for intervals (durations).
> But I don't have a copy of ISO 8601, and some googling fails to find any
> indication that anybody else believes this is a valid datetime format.
> Wikipedia for example documents a lot of variants of ISO 8601 [1],
> but nothing that looks like this.
There are additional formats in (the lesser known) ISO 8601-2, one of
which looks like this:
'1985Y4M12D', calendar year 1985, April 12th
But that is entirely incompatible with the above example, because it has
the units after the numbers.
Even more reason not to support the earlier example.
