Re: BUG #15141: Faulty ISO 8601 parsing

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Apr 2, 2018 at 5:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think you meant that this fails:
>> # select '2018-04-03T01:45:00,728456785+0000'::timestamp with time zone;
>> ERROR: invalid input syntax for type timestamp with time zone:
>> "2018-04-03T01:45:00,728456785+0000"
>> which it does, but I don't think we should do anything about it.
>> There is not and never has been any dependency on LC_TIME properties in
>> PG's timestamp I/O. Considering that we also have DateStyle to cope with,
>> as well as a lot more flexibility in the input parser than ISO 8601
>> contemplates, I think allowing a comma instead of decimal point here
>> would probably create more confusion than benefit.

> ​Ideally it would be as simple as:

> - /* Leading decimal point? Then fractional seconds... */
> - else if (*cp == '.')
> + /* Leading decimal point or comma? Then fractional seconds... */
> + else if (*cp == '.' || *cp == ',')

Well, it's not.

The core problem here is that the datetime input parser treats commas as
ignorable punctuation, equivalent to whitespace. For instance, we accept

# select 'sunday, april 1, 2018'::timestamp;
timestamp
---------------------
2018-04-01 00:00:00
(1 row)

but not

# select 'sunday. april 1, 2018'::timestamp;
ERROR: invalid input syntax for type timestamp: "sunday. april 1, 2018"

But surely it would not be a good idea to consider "T01:45:00,728456785"
the same as "T01:45:00 728456785".

Changing this would entail all sorts of side-effects on non-ISO
data formats. Considering that this code is about old enough to
vote, and this is the first complaint on this specific issue
that I can recall hearing, I don't even think it's worth the
time to investigate just what the side-effects would be ...
there's no way that any proposed change would get past the
backwards-compatibility hurdles.

regards, tom lane