"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