Talk:System time

When using kernel synchronization, according to this page the init.d script hwclock should NOT run at all, and/or the /etc/conf.d/hwclock file should have:

clock_hctosys="YES" clock_systohc="YES"

However, the comments in that file suggest the opposite:


 * 1) If you want the hwclock script to set the system time (software clock)
 * 2) to match the current hardware clock during bootup, leave this
 * 3) commented out.
 * 4) However, you can set this to "NO" if you are running a modern kernel
 * 5) and using NTP to synchronize your system clock.
 * 6) clock_hctosys="YES"
 * 1) If you do not want to set the hardware clock to the current system
 * 2) time (software clock) during shutdown, set this to no.
 * 3) clock_systohc="YES"

The way I read this, is that it should either be "NO" on both, or left as-is (that is, commented out, assuming "NO" is the default). It makes sense to me: The kernel syncs the time every 11 minutes, so if the script runs, there's no need to sync hctosys, nor systohc on startup or shutdown respectively.

Then, in the hwclock(8) man page, line 371, we learn the following:

''If your system runs with '11 minute mode' on, it may need to use either --hctosys or --systz in a startup script, especially if the Hardware Clock is configured to use the local timescale. Unless the kernel is informed of what timescale the Hardware Clock is using, it may clobber it with the wrong one. The kernel uses UTC by default.'' ''The first userspace command to set the System Clock informs the kernel what timescale the Hardware Clock is using. This happens via the persistent_clock_is_local kernel variable. If --hctosys or --systz is the first, it will set this variable according to the adjtime  file  or  the  appropriate  command-line  argument. Note that when using this capability and the Hardware Clock timescale configuration is changed, then a reboot is required to notify the kernel.''

Pretty much any regular PC (ISA) hardware clock uses a simple "ticks" timescale without leap seconds (as it has no way of knowing about leap seconds, unless the BIOS/UEFI implementation would inject them as needed even before an operating system is booted), eventually synchronized to UTC, or a zoned timescale based on it. "Fancy" hardware clocks (GPS or Radio-Controlled) may operate on any timescale, and I assume that's what the man page refers to, if a HW clock would indeed run on TAI, the kernel needs to know in order to adjust delta-t, if it would use UTC for the system clock.

So when we say a typical PC's onboard ISA RTC is "set to UTC", that is what happens whenever it's adjusted by the kernel or some userspace tool like hwclock, but it doesn't run in UTC (or a local timezone for that matter), it produces 60 ppm, i. e. it ticks at a constant rate and flip date fields accordingly, only accounting for leap years, but not leap seconds or daylight saving. It *may* seem to provide automatic daylight saving switching to an OS, if handled by a UEFI implementation prior to loading the OS. In any event, it works more like TT / TAI (albeit typically _not_ being set ahead of UTC) as it counts ticks (of a quartz, not caesium atoms of course, unless you have a very expensive PC... ;), instead of keeping track of a mean solar day (like, e. g. a radio-controlled device).

Well, I am not sure how that is relevant in the first place when using NTP, but oh well... The three documentation places seem to contradict each other in terms of what should or should not be done in the kernel-syncing case. Do we need to be more specific in distinguishing "precision" and "regular desktop" use cases and ISA HW-Clock vs. "fancy" HW-clocks?