Difference between revisions of "Talk:System time"

From ArchWiki
Jump to: navigation, search
(Fixing command for setting hardware clock in UTC time.)
m (use system time)
 
(53 intermediate revisions by 19 users not shown)
Line 1: Line 1:
Gog, why is it you're so determined to delete this?
+
== Windows time synch ==
  
I'm working on it and its a valid topic.
+
Can't you leave Windows time sync enabled and use the 0.pool.ntp.org server instead? --[[User:EoD|EoD]] ([[User talk:EoD|talk]]) 11:06, 5 July 2014 (UTC)
  
johnea
+
: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. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:03, 6 July 2014 (UTC)
:because it reads like a blog and its kinda wierd. compare it to the rest of the stuff. how to install this that BAM PHILOSOPHICAL BREAKTHROUGH
 
  
Ya know, a lot of the stuff on this wiki is just plain out of date.
+
::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)
  
Don't you think it would be more productive to try to find stuff that just doesn't even apply to the current arch system and update or delete that.
+
:::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? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 January 2016 (UTC)
  
Take a look at Arch64, there are 3 or 4 different ways of implimenting this and there is no contextual information on how or when these work together or when they are mutually exclusive. For instance, the "Current State of Arch64 Development" which is 2 years old.
+
::::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)
  
A lot of times things are at first done by individuals, then eventually some variation on the theme is included in the standard distribution. A wiki article describes the original work, but it's never updated to indicate that this is all build-in now.
+
:::::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 [https://wiki.archlinux.org/index.php?title=Time&type=revision&diff=414904&oldid=414633 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? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:32, 11 January 2016 (UTC)
  
There's a lot of specific information, but much of it is not current, and almost none of it is tied together.
+
::::::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)
  
It seems a lot of work could go into making the wiki more organized and relating the various topics to each other.
+
:::::::True, [https://wiki.archlinux.org/index.php?title=Time&diff=414907&oldid=414904 marked] as possibly inaccurate, with a link to this discussion. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:13, 11 January 2016 (UTC)
  
This would make a resource for arch users new and old.
+
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:
  
With all of this lacking in the current documentation, I don't understand the need to be some kind of self expression censor.
+
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
 +
      "RealTimeIsUniversal"=dword:00000001
  
this article started when I was investigating posix time and the recently passed leap second.
+
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. [[User:Bjourne|Bjourne]] ([[User talk:Bjourne|talk]]) 20:59, 8 June 2016 (UTC)
  
The fluffy stuff at the beginning is an introduction to the details.
+
== Systemd note ==
  
The next bit is a copy and paste from an email exchange with Jamie Zawinski and then some links saved at the bottom so they don't get lost before coming back around to it. The original intent of the article is to be about 3 times the current length.
+
[[System time#Time standard]] has a note which mentions:
  
After being a degreed EE in industry for 26 years it gets pretty fucking boring reading a bunch of acronyme enhanced techno bable in run-on third person sententences with the drilled down lack of context of an autistic plastic pocket protector.
+
{{Note|[[Systemd]] will use UTC for the hardware clock by default.}}
  
Additionally the "normal" non-weird style lends itself to almost immediate obsolescence because of its lack of context.
+
What does this mean exactly? systemd supports localtime, though it doesn't recommend it either; see timedatectl(1). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:38, 22 July 2016 (UTC)
  
I'm not sure what you do with your days, but over here there's a mortgage, a kid with the flu, three projects that need attention for clients, past due taxes, and plenty of other "normal" duties vying for my time. If I spend time writing about time keeping in unix computing, I want it to be fun as well as informative.
+
:This gives a more detailed explanation: http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/clock.html
  
I didn't realize the arch community had such strict standards of boringness.
+
:The article also mentions:
 +
::Later, the system clock is set again from the hardware clock by systemd, dependent on values in {{ic|/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 ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). '''To avoid it systemd [https://mailman.archlinux.org/pipermail/arch-dev-public/2014-August/026577.html 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]])
  
I've been running this distro for 6 years, pretty much every day. I'm not a maintainer, but I am a reasonably knowledgable user. I'd like to spread some of that knowledge to help arch users understand how their whole system fits together. A comprehensive understanding is not reached by each specific detail alone, it requires context and inter-relation.
 
  
The wiki should be THE ARCH BOOK. This requires that each article be maintained, not just a bunch of details that are correct in the moment but superfluous 6 months down the road. Otherwise it will always be in a shambles and mostly out of date with no cohesive vision that guides the reader or future contributions.
+
== <s>`timedatectl set-timezone` doesn't update `/etc/timezone` nor the xfce4-panel clock</s> ==
  
That's my bit.  
+
`timedatectl set-timezone` doesn't update `/etc/timezone`:
 +
https://unix.stackexchange.com/q/451709/143394
  
Best of luck...
+
For Manjaro, I raised it here: https://forum.manjaro.org/t/timedatectl-set-timezone-doesnt-update-etc-timezone/50684
  
johnea
+
xfce4-clock doesn't get updated timezone:
  
==<s>New initscripts and hwclock daemon</s>==
+
https://unix.stackexchange.com/a/451744/143394
With the latest initscripts package, the hardware clock is kept updated differently than how it's explained here (for example it's not in rc.shutdown any longer), I am still trying to understand well, so I cannot update the article by myself. For now I'm marking it as out of date. -- [[User:Kynikos|Kynikos]] 16:09, 3 May 2011 (EDT)
+
[[User:Ataraxy|Ataraxy]] ([[User talk:Ataraxy|talk]]) 07:25, 26 June 2018 (UTC)
:At the moment I link the bug report that seems to be responsible for this change: {{Bug|13684}}. -- [[User:Kynikos|Kynikos]] 16:39, 3 May 2011 (EDT)
 
::Understood and updated (also contributed by PeterL). -- [[User:Kynikos|Kynikos]] 06:17, 9 June 2011 (EDT)
 
:::Updated references to setting system time from hardware clock as I noticed things have changed again in the latest initscripts [[User:PeterL|PeterL]] 20:20 17 Dec 2011 (GMT)
 
  
==Note in the About section==
+
:{{ic|timedatectl set-timezone}} updates {{ic|/etc/localtime}}, {{ic|/etc/timezone}} does not exist in Arch. Closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:10, 30 June 2018 (UTC)
Hi there. I just got throught installing arch on a dualboot system. I saw how I can configure all this time-stuff, but didn't get what it is I'm supposed to be doing. (No problem following instructions, but.. what's the current situation, and what's the target?) Found this page, and read it. I only understood clock and time. So I played around (with UTC, changing BIOS clock, windows clock, linux clock, rebooted and looked at how the other clocks reacted). Then it was ovious. Reading throught the about section again I was puzzled why I didn't understand the concept perfectly on the first read, because it's all there, in detail.
 
 
 
So I added this note. I couldn't improve the About section itself, because it's all there already. But it's a lot of text with a lot of clocks (;) . I didn't want to dumb it down, and adding to it doesn't help the beginner, it's just more clocks. So I thought I'll just add a simple version of what's going on, seperate from the detailed information
 
 
 
But I know it's dublicated information, so someone might just delete it for that reason, and this is why i write here. Please don't delete it. It's a little bit of a chicken and egg problem, at least for me. This article needs a very basic explanation of what going on.
 
:Please sign your edits in talk pages.
 
:Don't worry, it's going to stay, I've just reworded it a bit and removed the Note template since it can't be considered a note. -- [[User:Kynikos|Kynikos]] 07:08, 15 October 2011 (EDT)
 
 
 
===<s>How to set Windows to use UTC</s>===
 
Is there a reason we don't provide info on [https://wiki.archlinux.org/index.php/Rc.conf#Localization how to set Windows to use UTC] here? Can I just copy-paste the note? -- [[User:Karol|Karol]] 09:02, 28 November 2011 (EST)
 
:You know that every time you write the word Win**** in the ArchWiki, god kills a kitten!
 
:Yeah copy-paste it ;)
 
:-- [[User:Kynikos|Kynikos]] 05:12, 29 November 2011 (EST)
 
::I don't like cats, I prefer llamas. Windows Windows Windows Windows ;P
 
::[https://wiki.archlinux.org/index.php?title=Time&diff=171563&oldid=170247 Note added]. Closing. -- [[User:Karol|Karol]] 07:00, 29 November 2011 (EST)
 
 
 
==hwclock daemon==
 
[[Time#hwclock daemon]] says that ''"[...] the {{ic|/etc/rc.d/hwclock}} daemon uses {{ic|hwclock}} to set the system and hardware clocks on boot [...]"'' but is that true? By looking at [http://projects.archlinux.org/initscripts.git/tree/hwclock hwclock's source code] it does nothing at boot. In fact that should be done by /etc/rc.sysinit as explained at the end of [[Time#Time standard]]. Probably somebody with good knowledge of the matter should come and clean things up.
 
 
 
This discussion is also related to [[Talk:Network Time Protocol daemon#Syncing at boot]].
 
 
 
-- [[User:Kynikos|Kynikos]] 11:03, 20 January 2012 (EST)
 
 
 
 
 
==Hardware clock and system clock==
 
[[Time#Hardware clock and system clock]] says that setting the hwclock based on swclock uses the command "hwclock --systohc", but I tested by myself this command and seems that without the UTC parameter ("hwclock --systohc --utc") its sets the hwclock in localtime.
 
 
 
This sounds a bit ambiguous because you can make an inference from what was said on above section ["To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.)"] that the "hwclock --systohc" will do the same.
 
 
 
(Get this info in section "Setting the hardware clock" on this link: [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clock and Time])
 
 
 
--[[User:Gbc921|Gabriel B. Casella]] 18:13, 11 March 2012 (EDT)
 

Latest revision as of 10:04, 22 October 2018

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

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


`timedatectl set-timezone` doesn't update `/etc/timezone` nor the xfce4-panel clock

`timedatectl set-timezone` doesn't update `/etc/timezone`: https://unix.stackexchange.com/q/451709/143394

For Manjaro, I raised it here: https://forum.manjaro.org/t/timedatectl-set-timezone-doesnt-update-etc-timezone/50684

xfce4-clock doesn't get updated timezone:

https://unix.stackexchange.com/a/451744/143394 Ataraxy (talk) 07:25, 26 June 2018 (UTC)

timedatectl set-timezone updates /etc/localtime, /etc/timezone does not exist in Arch. Closing. -- Lahwaacz (talk) 17:10, 30 June 2018 (UTC)