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
>
>
>