GNOME Bugzilla – Bug 697372
[MM 0.8] Time API inconsistent WRT UTC and local time
Last modified: 2013-04-26 06:07:57 UTC
The Time API specifies that the time is given as an ISO8601 string, which is defined to be local time. But we just pass through what modems give us here, which may be in UTC or not. FOr example, Icera devices: *TLTS: "13/04/05,15:46:18-20" give time in UTC with the offset from UTC indicating the current timezone. So a couple things should be done: 1) clarify in introspection XML that the GetNetworkTime() method returns an ISO-8601 format date/time string and that it is *local* time 2) modify all modems supporting the Time API to ensure they return the ISO 8601 string in local time
And, I would also add, include the timezone info *also* in the ISO8601 string itself... (in addition to the separate timezone value). We know we can gather the timezone independently, and sometimes that info is already enough, so a separate variable makes sense. But then, if you have the time string, why not add the timezone info in the string itself? That would really make a nice ISO8601 string with all the info we have, not just split into two variables. And that, actually, would make sure that the time we give is always associated to a timezone, except for when we don't know the UTC delta, in which case it would be OK to skip the timezone info from the string...
Please review dcbw/localtime. The Icera stuff is a pain in the ass because it's hard to convert from 'struct tm' to time_t (so we can add/subtract the offset) and back to 'struct tm', as most of the glibc functions for this sort of thing look at the system timezone and we don't want that. Also really odd that my Sierra USB305 (icera-based) only reports the time *once*, from the first time you query it. Seriously, the *TLTS reported time does not change. No idea what's up with that, perhaps we could ask Ben Chan to ping Sierra about it.
Just wondering, why not use GLib's GDateTime and GTimeZone API? It will probably allow playing with dates/times/timezones without messing around with glibc.
I wonder why I didn't think of that... branch updated, please review.
Looks much cleaner and easier to understand now. I pushed two additional commits to that branch, fixing a couple of things I found. Could you review those?
They look good, I suppose it's a good thing to have somebody on the other side of UTC test these :) We could also add some testcases for mm_new_iso8601_time() just to be sure, but whatever. Pushed, thanks!
Nah, I also thought about the unit tests, but probably they're not really worth it, once we have covered the obvious cases.