View Single Post
Old 09-04-2013, 12:55 AM   #8
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 46,881
Karma: 169810634
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by rjcroy View Post
A ha! Setting the time manually worked! Thanks very much for this tip. I had assumed that I couldn't set the time manually, and that it only got set by NTP syncing.

I supposed this might make sense if I recall that a Linux kernel keeps a separate time relative to the system clock time. Perhaps the system time was set to 1970, and the kernel clock obviously cannot sustain an off set of 40 years

Thanks for your suggestions everyone.
It's possible that Kobo limits the maximum time change on a NTP sync. We used to have issues with a couple of Unix servers that reset to 1970-Jan-01 on an extended power outage. The NTP daemon could only correct the real time clock by plus/minus 4 hours on a sync cycle so a maximum correction of 16 hours per day with our 4 NTP syncs per 24 hours. Oddly, the operating system time and date would display the current time/date after the first sync but on a restart, the hardware clock would revert to a time and date depending on how many time sync cycles had occurred.

Regards,
David
DNSB is offline   Reply With Quote