Talk:System time

From ArchWiki

Windows time synch

Can't you leave Windows time sync enabled and use the 0.pool.ntp.org server instead? --EoD (talk) 11:06, 5 July 2014 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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 time.windows.com, 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)Reply[reply]
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)Reply[reply]

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:

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
      "RealTimeIsUniversal"=dword:00000001

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)Reply[reply]

FWIW, there is a point in disabling Windows time sync, even when it does not make timezone mistakes: having only your Arch ntpd/chrony change the time gives it better estimate of how much your realtime clock is drifting. The Windows NTP implementation isn't very efficient at getting high precision with few queries after all. Of course only do this when you regularly boot into Arch. --Arthur2e5 13:42, 10 May 2023 (UTC)Reply[reply]

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.

This article or section needs expansion.

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)Reply[reply]

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)Reply[reply]

fake-hwclock

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)Reply[reply]

Run ntpd -qg; both parameters not listed at man page

The current text states:

Run ntpd -qg to manually synchronize your clock with the network, ignoring large deviations between local UTC and network UTC.

When trying to figure out what -q and -g actually does, the ntpd man page doesn't list either option.

Is this command really valid and functional? Probackup-nl (talk) 14:57, 19 January 2024 (UTC)Reply[reply]

https://man.archlinux.org/man/extra/ntp/ntpd.1.enandreymal (talk) 15:01, 19 January 2024 (UTC)Reply[reply]