Talk:Time

From ArchWiki
Jump to: navigation, search

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)

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 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)
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:

   [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)

Systemd note

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: http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/clock.html
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)