Fix timezone && fractional second handling of GetDateTimeFromW3CDTF
1) The timezone correction was inverted. Imagine we are parsing "2004-03-02T14:18:20+02". Before correction, aOslDTime contains "2004-03-02 14:18:20". According to the comment, we want to convert that to UTC time, so we have to *subtract* 2 hours, not *add* two hours. From http://www.w3.org/TR/NOTE-datetime: A time zone offset of "+hh:mm" indicates (...) a local time zone which is "hh" hours and "mm" minutes *ahead* of UTC. So if it is 14:18:20 in the timezone two hours ahead of UTC, it is two hours *earlier* in UTC, namely 12:18:20, and we need to *subtract* two hours, not *add* two hours. 2) Handling of fractions of a second was buggy: It reads only one digit after the dot. This could be a valid implementation decision to handle only deciseconds. However: 1) It then multiplies that by 10^9 (10e8 == 10*10^8, not 10^8!), and sticks that in the NanoSeconds field... That is 10 times too big: 0.3s == 3*10^8 ns 2) If there were additional digits, it then looks for the timezone offset specificator (beginning with '+' or '-') at these additional digits; it does not skip them: nOptTime is set to 0+3+2, i.e. to 5. Change-Id: I4738dc069e37f29c8bbd9e689689a933027af840 Reviewed-on: https://gerrit.libreoffice.org/4743Reviewed-by:Tor Lillqvist <tml@iki.fi> Tested-by:
Tor Lillqvist <tml@iki.fi>
Showing
Please
register
or
sign in
to comment