Re: BUG #15141: Faulty ISO 8601 parsing

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Apr 2, 2018 at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.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