Re: comma to delimit fractional seconds

Hi!
Thanks for the reply.

Consensus:
         Would anyone be likely to use this?  I've never heard of it before.
         And I haven't found any other mention of it other than the TODO 
list.
         So it comes down to risk vs standards compliance.

Breakage:   I don't think there is likely to be much breakage. The context
         would be only in the case of fractional seconds.  My proposed 
solution
         involves only one file for actual code changes, then some 
additional regression
         test cases.  Some of the risk may depend on how thorough the 
current
         regression tests are(?)

Proposed change:
     I propose changes to file backend/utils/adt/datetime.c.
     Most of the changes are to allow a comma to pass as a legitimate
     character in time strings.  The function ParseFractionalSecond()
     is modified to replace the ',' with a '.' so that strtod() still
     works. That means the heavy lifting with leading zeros and such
     is still done by the library function.


Chris Howard

p.s.  I've noticed that the error msg for badly formed time strings always
says the same thing "at character 13"  no matter how long the time 
string is.





On 06/23/2018 10:17 PM, Tom Lane wrote:
> Chris Howard <chris@elfpen.com> writes:
>> I looked at the TODO list and saw the issue of using comma to delimit
>> fractional seconds. ...
>> Is there anything more to it than allowing HH:MM:SS,####### as well as
>> HH:MM:SS.##### ?
> Here's the thing: most of the easy-looking stuff on the TODO list is
> there because there's not actually consensus about how or whether
> to do it.
>
> In the case at hand, what you'd need to convince people of is that
> there's not a significant penalty in terms of robustness (error
> detection) if we allow commas to substitute for periods.  There's
> a bunch of existing use-cases that depend on commas being noise,
> so it's not obvious that this is OK.
>
>             regards, tom lane
>
>
>