Talk:System time

From ArchWiki

Windows time synch

Can't you leave Windows time sync enabled and use the server instead? --EoD (talk) 11:06, 5 July 2014 (UTC)

I haven't understood, do you want Windows to manage your hw clock? In that case you'll have to keep it in localtime and let your other operating systems know, and disable any time synchronization methods they are using. You'll have problems with DST changes if Windows is not the first system you use after a DST change has been applied. -- Kynikos (talk) 04:03, 6 July 2014 (UTC)
Well, I do not think disabling the time synchronization in Windows should be recommended anymore, at least for Windows 10. I did the registry edit (RealTimeIsUniversal=1) using QWORD on a Win 10 64-bit system without needing to disable time sync (let alone touch the Win 7-esque internet time settings). I then rebooted Windows (the RTC adjusted to become UTC, shifting the windows clock back 6 hours (my local time zone is UTC-6) since Windows thinks that local time is UTC), then I disabled and re-enabled the "Set Time Automatically" option under Date & Time in the settings. The time automatically synced with the internet and adjusted time accordingly (and it worked for DST), all while the RTC was set to UTC. I rebooted into both Arch and Windows (as well as looking at BIOS settings) multiple times to confirm that it worked. The idea is that both Arch and Win 10 can sync the time without any problems. Should a section on this wiki page be created just to detail steps taken to ensure this harmony, all while RTC is on UTC? sb5060tx was here 00:34, 8 January 2016 (UTC)
If you can ensure that Windows doesn't mess with the RTC, you can let it sync the system clock as much as it wants. I don't understand the "otherwise it will mess up the hardware clock" statement in the article though: did (old) versions of Windows also update the RTC when syncing the system clock, despite the registry hack? — Kynikos (talk) 05:26, 9 January 2016 (UTC)
Maybe it did, but that sentence you are referring to had an to an external article explaining why to disable time sync in Win 7. The article said it in verbatim, that "Some governments in various countries implement daylight saving time on various dates and the public Internet time server is not updated with the change, thus showing wrong time by an hour." That article is quite old (2009), for I do recall as far as late 2013 that some of Windows Updates (I had 7) involved making sure DST was done at the right time in the right locations. And BTW, as I am typing on Win 10 right now, I realized that the time sync is with, the default. Then again, I do not have 7 anymore so I do not really know for sure. sb5060tx was here 19:01, 9 January 2016 (UTC)
If the only problem with time syncing in Windows is DST management, that's not something that belongs on the ArchWiki in the first place. Since the "mess up the hardware clock" part was too generic and unreferenced, I've removed the whole sentence: is it enough to close this discussion or are there more references to Windows time syncing that I didn't find? — Kynikos (talk) 03:32, 11 January 2016 (UTC)
From the first paragraph of UTC in Windows: If you make Windows use UTC, also remember to disable the "Internet Time Update" Windows feature, so that Windows does not mess with the hardware clock, trying to sync it with internet time. You should instead use an agent for the NTP to modify the RTC and sync to internet time, see #Time synchronization.sb5060tx was here 03:36, 11 January 2016 (UTC)
True, marked as possibly inaccurate, with a link to this discussion. — Kynikos (talk) 04:13, 11 January 2016 (UTC)

Just want to confirm that it is possible to get Windows 10 to use a hardware clock set to UTC. The article is not clear about that. First you import the regedit key:


And it should be dword on 64bit Windows too. Then you need to go to Date and time settings and set "Configure time automatically" and "Configure timezone automatically" to off. Then if you configure the hwclock in Arch it won't be overwritten by Windows. Bjourne (talk) 20:59, 8 June 2016 (UTC)

Systemd note

System time#Time standard has a note which mentions:

Note: Systemd will use UTC for the hardware clock by default.

What does this mean exactly? systemd supports localtime, though it doesn't recommend it either; see timedatectl(1). -- Alad (talk) 18:38, 22 July 2016 (UTC)

This gives a more detailed explanation:
The article also mentions:
Later, the system clock is set again from the hardware clock by systemd, dependent on values in /etc/adjtime. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea (there is a lot more to it). To avoid it systemd will only synchronize back, if the hardware clock is set to UTC and keep the kernel uninformed about the local timezone. As a consequence timestamps on a FAT filesystem touched by the Linux system will be in UTC.
All that linked discussion mentions is how systemd doesn't mention the kernel on the time zone if the RTC is set to localtime. It doesn't say anything about "synchronizing back", or UTC and time zones. -- Alad (talk)
As of this writing, a fuller quote of this note is
If /etc/adjtime is not present, systemd assumes the hardware clock is set to UTC.
And before that, System_time#Time_standard states
The standard used by the hardware clock (CMOS clock, the BIOS time) is set by the operating system. By default, Windows uses localtime, macOS uses UTC, other UNIX and UNIX-like systems vary. An OS that uses the UTC standard will generally consider the hardware clock as UTC and make an adjustment to it to set the OS time at boot according to the time zone.
Further more, quoting System_time#hardware clock
Only 2016, or later, UEFI firmware has the ability to store the timezone
I believe many systems today have UEFI firmaware.
In short, it looks to me justified to follow Help:Discussion#Closing_a_discussion. Striking the header using <s> tags. Regid (talk) 15:10, 17 October 2022 (UTC)

Proposed changes to the introductory paragraph

The intro paragraph needs a better overview to include the functional importance of the system clock, the hardware aspects (like CMOS battery), and how system time affects date/time stamps on system files and impacts system processes and updates. The current 'needs expansion' flag still applies and is moved to the end of the intro paragraph.

The below draft can be edited here as part of discussion of this and other proposed changes:

System time governs critical processes of an operating system, from local date/time stamps on system files or emails to system upgrades. Review the Linux System Administrators Guide for more details about keeping time.

Two clocks are present on systems: a hardware clock and a system clock. Computers use a battery on the motherboard to retain system time when the device is not powered. This is the hardware clock. In an operating system, the system clock is determined by three parts: time value, time standard (whether the time value is in local time or UTC or something else), and time zone (which may include Daylight Saving Time (DST) if applicable). This article explains what they are and how to read/set them.

Standard behavior of most operating systems is:

  • Set the system clock from the hardware clock on boot.
  • Keep accurate time of the system clock, see #Time synchronization.
  • Set the hardware clock from the system clock on shutdown.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: This article mostly documents systemd timedatectl; explain basic commands like date and hwclock first (Discuss in Talk:System time)

Stuthtle (talk) 18:26, 6 October 2021 (UTC)

I've edited the draft to better describe what are the three parts of system clock. I don't like the term "time standard", but that's what the page currently uses... ¯\_(ツ)_/¯ — Lahwaacz (talk) 17:36, 12 October 2021 (UTC)


The functionality offered by fake-hwclock as listed in the article is mostly redundant. Systemd's systemd-timesyncd offers the same functionality where it continuously saves the current timestamp to a file. I think the recommendation should be to use systemd instead, as it does not require installing additional tools.

Bertptrs (talk) 06:22, 1 April 2022 (UTC)