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