Charm
Charm copied to clipboard
KDAB
Wrong calculations when clock is changed during tracking
On startup, my machine has a wrong clock setting - it is one hour in the future. Then, after a few minutes, ntpd kicks in and fixes the clock and rewinds it one hour.
This leads to bugs in charm when I start tracking before ntpd kicks in. I.e. just now I got this:
boot up, clock at 14:00 start charm, event window shows start at 14:01 ntpd kicks in, sets clock to 13:02 -> charm event window shows event with -59min time delay...
If I wouldn't have seen it just now, I would have lost >1h of my time (happened some days earlier as well).
Hmmm... Charm should be DLST safe IIRC, might your RTC be fast or some such?
Alternatively, if this happens a lot you might want to consider running ntpdate before launching ntpd (that's what I do). It might slow down your boot time, but you can be sure your system won't time-travel on you.
Now as for Charm, I guess we could work around this issue by storing an init timestamp and use that to compensate for drift. That said, I'm just not sure if it might be worth dealing with this edge case, it all depends on how much we want Charm to trust that the system is doing it's job (and keeping correct time). Perhaps @frankosterfeld can chime in. :)
My hwclock was off, which I've fixed now. I'll keep an eye on charm next week to see whether it works properly now.
I don't know about long running time measurings on a computer, but considering we already update the GUI every minute could we maybe show a warning when the clock was changed significantly? I.e. normally we'd expect an increase of 1min. If suddenly the new time is considerably off, e.g. negative change or a change of multiple minutes, we could tell the user. Then its his job to take care of this?
Better that imo than no hint at all and potentially losing hours of tracked worktime?
Hm but my proposal above rises the question, on how to handle time changes like summer time -> winter time or leap years... I.e. that should be handled automatically without showing a warning. But you said you handle that already? So maybe it could work?
Time is stored (and IIRC compared) in UTC so that should be DLST safe. Leap year safe... perhaps. :)
All times are stored and handled in UTC, yes. We had the summer/winter time bug triggered before and the handling was changed to UTC to handle exactly those issues. If there's a remaining issue, I'd be interested in test cases.
http://www.qtcentre.org/threads/31900-detect-system-time-change
In short: A QTimer that is triggered eg each second and checks if current timestamp differs much from last remembered timestamp and then eg adjusts the logged starttime by that difference.
Note that in the past I had similar problems with my Laptop sometimes being in the wrong month/year. I found the "solution" to upgrade to opensuse 12.2 and the there integrated systemd refuses to boot, requires root login, clock adjustment and 3 reboots in total if time went backwards since the last boot (what I have to do at least once a week now). Yay! :)
Yeah, that was pretty much what I had in mind. Now a cool feature would be integrated NTP support.
I'd like to avoid a wake up per second though, Charm already is enough of a battery drain as it is...
NTP integration sounds better and better. :) Or perhaps I just like making fun tasks for myself.
I'm a huge advocate for ntpdate on boot and resume, it's kept me from having this problem (though not perfect if you travel a lot).
An alternative to integrating NTP would be for us to do a simple HTTP HEAD request to a server and use that to see if the current running system is way out of date, then warn the user (or use that as a time differential and just compensate).