On each boot into Arch, I see that the time is off by a few minutes. The RTC time is off (as far as I understood, it has "drifted".) and affects the hardware clock.

$ timedatectl status
                      Local time: Mo 2018-02-12 12:45:18 CET
                  Universal time: Mo 2018-02-12 11:45:18 UTC
                        RTC time: Mo 2018-02-12 11:45:18
                       Time zone: Europe/Berlin (CET, +0100)
       System clock synchronized: no
systemd-timesyncd.service active: no
                 RTC in local TZ: no

EDIT Upon writing this post, I did not realize that the time values above this line are coherent to another. However they have an offset to my watch and smartphone time which is the aforementioned 7 minutes.

And my locale:

$ locale

So far I am very reluctant to use hwclock --hctosys as the man page states:

This function should never be used on a running system. Jumping system time will cause problems, such as corrupted filesystem timestamps. Also, if something has changed the Hardware Clock, like NTP's '11 minute mode', then --hctosys will set the time incorrectly by including drift compensation.

As far as I can tell, I configured Windows 10 correctly. Is there something I am missing or did I not set the clock up correctly?

EDIT 2 Upon request, the contents of /etc/ntp.conf:

# Please consider joining the pool:
#     http://www.pool.ntp.org/join.html
# For additional information see:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - http://support.ntp.org/bin/view/Support/GettingStarted
# - the ntp.conf man page

# Associate to Arch's NTP pool
server 0.arch.pool.ntp.org
server 1.arch.pool.ntp.org
server 2.arch.pool.ntp.org
server 3.arch.pool.ntp.org

# By default, the server allows:
# - all queries from the local host
# - only time queries from remote hosts, protected by rate limiting and kod
restrict default kod limited nomodify nopeer noquery notrap
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntp.drift
  • Windows will use an NTP daemon by default which will automaticly re-sync your system clock with one on the internet. Linux might not have this switch on by default. It depends on distribution. Is it 7 minutes regardless of how long you left it switched off? Does booting windows in-between booting linux make a difference? Either way, look into installing ntp or ntp-date. These will allow your linux machine to automatically correct it's HW clock error. NTP will actually monitor for drive and adjust for it. Feb 12, 2018 at 11:46
  • Would you please add your /etc/ntp.conf file to the answer? Feb 12, 2018 at 12:06
  • "Is it 7 minutes regardless of how long you left it switched off? " Yes. Can't answer the other questions yet. @couling
    – henry
    Feb 12, 2018 at 12:12
  • @RuiFRibeiro Info added!
    – henry
    Feb 12, 2018 at 12:14
  • @henry Has my answer helped? Feb 12, 2018 at 13:27

3 Answers 3


If you have a larger time difference between the real time and your RTC as you have when booting, you can configure NTP to over compensate for that in one go after start, instead of doing it slowly and incrementally over time.

I would add to your /etc/ntp.conf file as the first line (it has to be the first line):

tinker panic 0

tinker panic - Specifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.

Whilst this may solve the Linux time problem in the present, I would also investigating over time the underlying causes of the time drift between the two OSs.

  • 1
    The OP should keep this setting until the clock of his machine is in sync, then replace it with tinker panic 300 or a similar value to avoid big clock drifts.
    – dr_
    Feb 12, 2018 at 14:13
  • 1
    Ever since I installed a certain Windows 10 update (I do not recall its specific name unfortunately), the hwc offset was corrected. Wish I could tell you more than that, but I am happy that it works again... on its own. :)
    – henry
    Nov 23, 2018 at 9:27

Since the timedatectl command reports that the "Universal time" (i.e. the kernel's idea of UTC) and "RTC time" are in sync, the real-time clock is in UTC time and the time has been successfully transferred from the RTC to the kernel clock at boot.

But the System clock synchronized: no would indicate that ntpd is not successfully syncing, possibly because the difference between the real UTC and the system's idea of UTC is too great. Rui F. Ribeiro's answer was aimed to fixing that.

You should check the contents of the /etc/adjtime file. The first line should contain three values, separated by spaces. The first is the assumed systematic drift rate of the battery-backed RTC, in seconds per day. The second value is a UNIX timestamp of the most recent time the RTC was adjusted for drift.

If the drift rate is erroneously large (possibly because the RTC was adjusted by another OS while it was running, which was misdetected as RTC drift), it might cause the 7-minute error at boot.

Since the drift rate correction is applied at boot time when the time is copied from the battery-backed RTC to the kernel clock, any error caused by an incorrect drift rate can be propagated to the kernel clock too. That would explain why both clocks are in sync with each other while being 7 minutes off real UTC. It also means running hwclock --hctosys would not fix the problem.

if the drift rate in /etc/adjtime is abnormally large, you should set it to zero or even wipe the entire file, to stop the incorrect drift rate correction from adjusting your clock. If the system clock is going to be synchronized with NTP, it will normally propagate the synchronized time to the battery-backed RTC too.

If you want to set /etc/adjtime to automatically compensate for "cold" drift rate (i.e. drift that happened while the system was down or running another OS), then you could use the following procedure:

1.) Review your startup and shutdown scripts to ensure you understand all points where system clock or the battery-backed RTC is operated.

2.) Pick a time when the system will be down for a relatively long time (minimum 4 hours; overnight or over the weekend would be better). Then temporarily disable all automatic NTP synchronization. Make sure initramfs scripts are covered too.

3.) Just before shutting down the system, make sure the system clock is in correct time, then run > /etc/adjtime; hwclock --systohc --utc --update-drift. Verify that /etc/adjtime now has 0.0 as the first value of the first line, and the current Unix timestamp as the second value of the first line + as the only value on the second line, and the third line says UTC. Then shut down the system.

4.) After starting up the system again, use ntpdate or some other method that only sets the kernel clock to get the system to accurate UTC time. Then run hwclock --systohc --utc --update-drift again. Now the first value in /etc/adjtime should be updated to match the rate the RTC drifted while the system was down.

5.) Then make sure no startup/shutdown/cron job runs hwclock --update-drift automatically; on a NTP-synced system you would only want to update the drift rate when you know for sure nothing has adjusted the RTC over the time period you're using for drift rate estimation.

6.) Finally, re-enable NTP synchronization. If you dual-boot with two or more OSs, ideally only one OS should be doing adjustments to the RTC; otherwise drift rate estimates will be inaccurate.


I haven't checked for recent Linux kernels, but older ones had a very odd code to update the RTC from the system time (in RAM). Many years ago I had tried to fix that, but that code never made it to the kernel.

I think current systems update the RTC from system time on shutdown or reboot (if enabled).

If your distribution does not provide a mechanism, you could add a cron job (or systemd timer) to update the RTC periodically.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .