You are not logged in.
Noble Folks,
I would like to contribute an information to the ArchWiki and I don´t know how. On the System Time section describes how to turn off Linux UTC or how to force Windows to use UTC, but there is a simpler way to do it that is to force Windows to sync time at startup. (for those with dual boot)
Open start menu:
Type Task
Choose Task Scheduler (even in pt_BR it showed up "agendador de tarefas")
When it is opened, at the right side click in "Create Basic Task"
Write the Name and Description you want and hit next (I went with "Time Sync" and "Sync Windows Time at Startup")
When do you want the task to start? Select "When the computer starts" and hit next.
What action do you want the computer to perform? Select "Start a program"
Program/Script: (either browse or type) "C:\Windows\System32\w32tm.exe" (on older windows it might be called "w32time.exe", look what is right for you on /Windows/System32)
Add arguments (optional): type "/resync" and hit next
Finish, you are all done ![]()
The "" is just so you know what to type, dont use them on those fields.
So instead of changing how the SO works with time, we just request an synchronization with Microsoft Timer Server.... (Similarly like Linux updates with UTC)
(It is similar to go in "adjust date and time" and click the "sync now" button, we just automated it)
There is probably an easier way to do it with command line, but I dont know how, you can find the information about it here https://docs.microsoft.com/en-us/troubl … dule-tasks
I hope it helps.
Last edited by Soultrigger (2021-11-11 22:10:16)
Offline
It seems I screwed up, there is a forum for the wiki, can someone move it there? Thanks.
Offline
Add an item to the relevant Talk page. But, it is the Arch Linux wiki, not the Arch Windows one, so don't expect much support for the idea.
Offline
It may be reasonable to include the option to sync time at boot up in both OSs, but all the details of how to do that in other OSs is out of scope for our wiki.
That said, wouldn't this result in a hardware clock that is not reliable in either system until it is synced during boot which could very easily fail for countless reasons such as not having an active internet connection at that moment? Why would one want to deliberately chose such a fragile strategy when much more robust approaches are easier. In other words what's the benefit (or the point) of this approach?
Last edited by Trilby (2021-11-11 17:10:08)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I dont know about technical implications. What I know is that who is on linux says to dont turn off UTC and systemd complains about it in a very serious way and who is on Windows says to dont force the OS to use UTC because it will have serious implications. I just thought since Linux syncs and changes the computer clock whenever I boot into it, if Windows would do the same, it could be a good match without screwing either OS. Of course, my machine clock will go crazy...
But why would that be bad? Since Linux syncs and change time at "boot"...
Thanks to help me think it over though and teach me better ways...
Last edited by Soultrigger (2021-11-11 17:58:25)
Offline
It's already pointed out above, any approach that relies on a 24/7 internet connection to not have an X hours time difference is too fragile to include. Having Windows use UTC instead is hardly complicated.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I dont know about technical implications. What I know is that who is on linux says to dont turn off UTC and systemd complains about it in a very serious way and who is on Windows says to dont force the OS to use UTC because it will have serious implications. I just thought since Linux syncs and changes the computer clock whenever I boot into it, if Windows would do the same, it could be a good match without screwing either OS. Of course, my machine clock will go crazy...
The windows reasons are practically irrelevant: Backward compatibility with dual booting XP and older as well as some users that cannot cope with UTC time when they have to enter the bios for some reason: https://devblogs.microsoft.com/oldnewth … 0/?p=37983
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
I see, thanks for educating me. I didnt think in every case, just my own. (which basically meant correcting time when logging in windows to do my work (vpn issues)). Thanks all for taking your time to show the wrong approach in my idea. I will mark as solved.
Edit: Disabled my task and went with UTC for Windows, after all it seems more "avoid user confusion" rather than being something technical.
Last edited by Soultrigger (2021-11-11 19:27:03)
Offline
Note that the "normal" time sync at boot up (which actually isn't default, but may be a fairly commonly used service) will only be adjusting by fractions of a second in most cases unless you've got a borked hardware clock to begin with. In fact, some time sync programs (i.e., ntpd) will *not* make a large adjustment in the time unless you give it an additional command line flag to allow for large adjustments.
When the boot-time service is just making fine adjustments, there will be no problem if it happens to fail periodically - in the worst case, your clock may be off by a fraction of a second: you'd never notice. But being off by several hours would be a hassle, and could cause other problems.
But my bigger point was that it makes no sense to require *both* OS's cope with a hardware clock that's not in their preferred mode. It's not surprise that most users of these forums would suggest setting the hardware clock to the linux-preferred UTC and make windows deal with it (which windows can). But I'd see nothing really wrong with setting the hardware clock to local time, and making linux deal with it (which linux can). I'd not really like this personally, but it's not unreasonable.
What is unreasonable is keeping the hardware clock in a state that is good for *neither* OS requiring *both* of them to cope with it not being in the preferred mode. And worse yet, doing so in a way that is effectively non-determinisitc: neither OS could even adapt because they'd not know if the hardware clock was in their preferred mode or not until there was an internet connection and an accessible internet time source - at which time there'd be a roughly 50/50 chance that the sync would result in an awkard several hour offset in any active logs.
In short, keeping the hardware clock in localtime is not as good as keeping it in UTC, but *either* of these would be far better than constantly resetting it and having it in an unpredictable state at any given moment.
Last edited by Trilby (2021-11-11 20:27:25)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for such a nice explanation, I loved to read it.
In my personal case when I log to Linux he would get the right time, but when I left Linux and went to Windows he would get +3 hours difference from my real life local time. I decided to force Windows to use UTC. Reading more and since you all explained more now I do understand the machine time matters, if for nothing else, to have FS and Logs in the right date and time, etc. I also didnt think this trough for those machines which wont have internet connection, neither if it was worth it to get time from net services instead of setting properly my hardware clock.
Even though my idea was demolished, I really appreciate a straight talk to the point. Thanks for being technical and help a noob be a little less newbe.
Offline