Talk:System time

Kernel time sync
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?

The last reverted post
My recent post was reverted as "not necessary", but I believe mine has good reasons.


 * "Use UTC if you don't have any idea" is not absurd. William Hubbs (williamh, the OpenRC lead) says at bug #671574#c3 that "[kernel] has a very strong preference for the hardware clock being in UTC."
 * The timestamp of OpenRC log is wrong if the RTC is localtime. See this.
 * Notice no one forces UTC; simply if you use localtime, you may face some troubles, and you have to accept, or at least anticipate it.
 * Clock getting drifted by hours is a recurrent issue in Linux, if not what everyone undergoes. See, , ...
 * Or if there's a hardware fault, typically with the RTC battery, RTC can drift say by minutes everyday.
 * That's why I posted a convenient way to use the "date" command to fix such drifts.
 * When the system clock error is too big (by more than 1000s), /usr/sbin/ntpd won't fix it by default. In that case you need a manual fix with the "date" command (or pass "-g" to ntpd. )
 * And isn't it obvious it's not "configuration", and should be in a separate section?
 * (Rant: the current example "050612342016" as "12:34, May 6, 2016" furiates me. Why assume MMDD as late as in 2016?)
 * Dual booting with MSWin has an annoying background. For those who experienced failure in the past, it's good to tell it's historic. Then the pointer to the Arch Wiki article is inevitable.
 * At the very least the current Gentoo article lacks the dword/qword point. Even williamh referred to the Arch artcile in the above mentioned bug. :p

My previous post was an attemp to (help to) solve the bugs and  for some part. (In fact the latter was closed as INVALID but the reporter was not convinced. I understand it.)

Regards. --Teika (talk) 07:15, 19 April 2019 (UTC)