In older Fedora versions, the system clock was synced down to the RTC at shutdown. We dropped this a while ago, since without knowledge that the system clock was accurate and in which mode the RTC clock is used (local or UTC) we shouldn't touch the RTC, and systemd generally does not have this knowledge. Now, chrony is in a much better position to know when the system clock is accurate, as making sure of that is pretty much is job and since for that it implements NTP and includes code to deal with RTC skews. As the kernel already syncs minor clock changes on its own (via the 11min mode), we'd like to see chrony sync big time jumps (i.e. the initial clock jump if there is one) to the RTC as well, so that all bases are covered. The are multiple ways to implement this: a) I'd recommend simply patching the chrony C code to sync big time jumps down to the RTC device. This means that big jumps are immediately reflected in the hardware, and the time correction is not lost on power failure and similar occasion. This is the cleanest and most robust solution, in my opinion. b) hwclock -w is invoked as part of the chrony unit files at the right point in time, i.e. after big time jumps. Alternatively via a cron job/timer unit, if that's desired. c) hwclock -w is invoked at shutdown, but this has the negative impact that time correction is lost if power is turned off abruptly or the machine otherwise dies without a clean shutdown. This behaviour comes closest to the behaviour of old Fedora, but is probably the least desirable. Either way this logic should only be done if chrony is installed and enabled as only then the system clock is known to be accurate enough. If a) is implemented this will be the case automatically. If b)/c) is implement a nice way would be to pull the sync units if chrony is enabled, i.e. via Also= in the [Install] section of the units. Please add a C patch to chrony for this (a), or alternatively package unit files invoking hwclock for this (b/c). Thanks!
Note that this bug is probably not of highest priority since this currently only affects systems with clocks off for more than 30min, and an easy work-around exists (hwclock -w).
I think we need to reach a conclusion in the bug #816752, before we start patching every program which can set the system clock. Some points: - chrony includes a code which tracks the RTC drift, but it obviously can't work when the kernel 11-minute sync is enabled - with the 11-minute mode, setting the RTC only once on the first sync may be not enough if there are long periods of time when the computer is not synced via NTP - chrony needs to be told whether the RTC is in LOCAL or UTC too - the RTC tracking feature in chrony is considered obsolete, since hwclock does a better job at this as its measurements include the time when the machine was powered down and the drift was different due to lower temperature of the crystal - there is probably a better place for the hwclock -w service or cron job than every package which can set the clock *** This bug has been marked as a duplicate of bug 816752 ***