Thread: comma to delimit fractional seconds

comma to delimit fractional seconds

From
Chris Howard
Date:
I'm new at this.

I looked at the TODO list and saw the issue of using comma to delimit 
fractional seconds.

I looked at the parser stuff and I think I have at least a start on the 
issue.

Is there anything more to it than allowing HH:MM:SS,####### as well as 
HH:MM:SS.##### ?

Is it OK if it works that way in all timestamps, not just 
ISO-8601-compliant cases?


Chris Howard







Re: comma to delimit fractional seconds

From
Tom Lane
Date:
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


Re: comma to delimit fractional seconds

From
Chris Howard
Date:
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
>
>
>



Re: comma to delimit fractional seconds

From
Chris Howard
Date:
>
> 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.
>

nevermind, user error