Thread: Kobo Bug thread
View Single Post
Old 01-23-2018, 07:15 PM   #973
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by compurandom View Post
I think you missed a point. No, I don't think calibre should compensate for a drifting clock.
And that I missed your point was the point of my post. You made a statement without any real qualification of what you were referring to. I then stated the possibilities based on what the recent discussion in the thread.
Quote:
Yes, I do think calibre should be compensating for the device using UTC when the local OS may use UTC or localtime. The teeny bit of code I've already looked at appeared to be making this adjustment, although I'd have to think about it really hard to figure out if it was doing it correctly.
The driver should be doing it correctly, but it doesn't matter much. It doesn't really use any timestamps that are read from the database. The only one I can think of is the date displayed in the device list. It does set timestamps when creating collections, but with the way those work, they won't matter much if they are out.

The Kobo Utilities plugin does more with the timestamps, and they should be correct.
davidfor is offline   Reply With Quote