[Asterisk-code-review] cel odbc: Fix timestamp processing for microseconds (asterisk[14])

George Joseph asteriskteam at digium.com
Fri May 5 13:00:17 CDT 2017


Hello Jenkins2,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/5590

to look at the new patch set (#2).

Change subject: cel_odbc:  Fix timestamp processing for microseconds
......................................................................

cel_odbc:  Fix timestamp processing for microseconds

When a column is of type timestamp, the fraction part of the event
field's seconds was frequently parsed incorrectly especially if
there were leading zeros.  For instance "2017-05-23 23:55:03.023"
woiuld be parsed into an int as "23" then when the timestamp was
formatted again to be inserted into the database column it'd be
"2017-05-23 23:55:03.23" which is now 230 milliseconds instead of
23 milliseconds.  "03.000001" would be transformed to "03.1", etc.

* If the event field is 'eventtime' and the db column is timestamp,
  then existing processing has already correctly formatted the
  timestamp so now we simply use it rather than parsing it and
  re-printing it. This is the most common use case anyway.

* If the event field is other than 'eventtime' and the db column
  is timestamp, we now parse the seconds, including the fractional
  part into a double rather than 2 ints.  This preserves the
  magnitude and precision of the fractional part.  When we print
  it, we now print it as a "%09.6lf" which correctly represents the
  input.

To be honest, why we parse the string timestamp into components,
test the components, then print the components back into a string
timestamp is beyond me.  We should use parse it, test it, then if
it passes, use the original string representation in the database
call.  Maybe someone thought that some implementations wouldn't
take a partial timestamp string like "2017-05-06" and decided to
always produce a full timestamp string even if an abbreviated one
was supplied.  Anyway, I'm leaving it as it is.

ASTERISK-25032 #close
Reported-by: Etienne Lessard

Change-Id: Id407e6221f79a5c1120e1a70bc7e893bbcaf1938
---
M cel/cel_odbc.c
1 file changed, 52 insertions(+), 29 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/90/5590/2
-- 
To view, visit https://gerrit.asterisk.org/5590
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Id407e6221f79a5c1120e1a70bc7e893bbcaf1938
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: 14
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2



More information about the asterisk-code-review mailing list