Hardware clocks?
 

I'm confused about Hardware clocks. I've viewed multiple wikis on it but it just doesn't make sense... Why should the time between OS's even matter? So what if my Windows counts time differently than Mac? (/Linux)


In addition to just understanding the concept^, please help me: how should I set up the hardware clocks for a triple boot system with Windows 10, Arch Linux, and Mac OS X Yosemite?

Rightly so. Hardware clocks are confusing, because they are an antiquated piece of (expletive deleted) left over from the original pc spec. Esee the things they did with A20? (the address bus line).

There is no right way to handle them. Decide what single statement of time it will store.

The sole purpose of the hardware or RTC clock is to set the system clock when the computer is powered on. Windows expects the hardware clock to be set to local time and linux defaults to UTC but can configured as local. If dual booting it should be set for local time and then when installing linux there will be a configuration page that sets the time zone and hardware clock setting for local or UTC.

The only reason it matters is that the linux system clock is based on UTC and if the hardware clock is not configured correctly the displayed time, logs etc will not be correct. It may not be important for the home user but but time synchronization is critical is in a domain environment.

I suggest installing NTP (Network Time Protocol) which will keep the system/hardware clock accurate.

The system clock is basically a counter where 0 = 00:00:00 (UTC), Thursday, 1 January 1970, If the operating system does not know how the hardware clock or timezone is configured as stated the display as well as all time stamps will be wrong.

Set the clock to UTC and make Linux and OS X happy. Then tell Windows that the time is in UTC (and you want it to stay that way). https://wiki.archlinux.org/index.php...UTC_in_Windows

I don't quite agree that hardware clocks are antiquated, as some method is needed to remember the time while a computer is powered off, but coordinating the hardware clock and the system clock under *nix can be truly annoying.

I once was dual-booting Slackware and Fedora. Slackware was set to UTC, but for some fool reason (probably something I overlooked during the install), Fedora was set to local time. That led me to learn the date and hwclock commands. Well, "learn" is probably not the right word, as I always have to consult the man pages; "familiarize" might be more accurate, because, really, it's not something you have to deal with very often.

Once you set the time with the date command, which for me is the the easiest way to set the date once you get the hang of the format, you can use

to set the hardware clock to the system clock.

From the hwclock man page:

I find 'hwclock -hctosys OR -systohc helpful, as is man date. Then sort it and move on. If the same error always shows, add a command to rc.local and sort it.

Hi
Don't understand
How would the PC know the current time and do absolute-time-related things if it wouldn't have the current datetime? (and it doesn't have an Internet connection with which to retrieve the current time OR the timesource does not work or provides the wrong time because it's corrupted)?

This is what I did on this laptop (possibly even using the page linked to) and I dual boot Debian and Windows 10 with no time issues now.

Thanks for confirming it still works with Win10.

Also, I gave instructions in reverse. First, you should tell Windows not to mess with your system time, and then you should boot into BIOS and set the time to UTC.

Thank you both very much. So the first answers what my original question basically was, I don't know if I made it clear enough; basically I didn't know what issues, if any, having different clocks set up would cause. I figured, so the different OSs will have different times, oh well? I mean I'm still a bit confused but ah ok, it can cause problems and that's why they say to make sure they match?

the second makes me question what to do because the first guy said he did the original steps and now you're saying to do them the other way around.

So to fix the hardware clocks issue, what should I do? (Please get it right this time and that's not to sound rude I just don't want to mess anything up!! :) Haha sorry if it sounded rude I surely don't mean it to)

OK, to try to answer logically:
The hardware clock is set to a time, let's call this hardware time.
When Linux boots it assumes that hardware time is UTC, or Coordinated Universal Time*, which is a kind of "time zone 0" upon which all time zones are then based. The Linux system checks the time zone which your system is set to and adds or subtracts from this to display what we'll call display time. This display time is used whenever you ask the system to display something like the last time a file was modified.
When Windows boots it assumes that hardware time is the correct time in your time zone so it simply sets display time to hardware time.
To complicate things Linux and Windows [slightly less commonly] can synchronise time to the internet and then set the hardware clock appropriately -- Linux will set the hardware clock to true UTC and Windows to the true real time in your time zone.
The above means that dual booting usually means that one or both the operating systems displays the wrong time.
To resolve this one either sets Linux to assume hardware time is the local time of your system or sets Windows to assume that hardware time is UTC.
Personally, I think it is better to set Windows to assume that the hardware is set to UTC. This is for a few reasons but mainly because I think it is "neater" and more easy to understand and because if, for some reason, the time zone information in one of the operating systems is wrong (more likely to happen around daylight savings time) the hardware clock should remain at UTC so the other OS should be unaffected.

For completeness things like file opening and modification times under Linux are stored as Unix or Epoch Time which is the amount of time which has passed since 00:00:00 UTC on 1 January 1970.


*Yes, the initials seem in the wrong order, this is for political reasons explained in the Wikipedia article.

In actuality Linux uses hwclock as reference at boot, then runs on its own. Linux may or may not (depending how it is set up) write the time back to hwclock at shutdown.

Awesome reply. I get it now!! :) So how do I go about setting Windows to UTC time? I hear this involves messing with registry and stuff and don't want to mess anything up.

This reply links to the necessary registry edit.For what it's worth I googled around and found the same answer in multiple places then tried it and it worked.
I have actually told both Linux and Windows to set their time using the internet but that is optional. One thing I would advise is to set that registry value, reboot into Windows, set the time correctly in Windows (it may have changed quite a bit from your local time) then reboot into Windows again and check it has stayed. Then boot into Linux, check the time is OK, then reboot back into Windows to ensure nothing has gone awry. I have to admit to not having set my Linux system to local time so I'm not sure how one changes between local time and UTC if you are in that situation but the Arch page linked to should give some help.
I have to admit to being a little fascinated by time zones and UTC offsets to the extent that I tend to talk in 24 hour ("military time" to those in the US), wear a watch with the ability to show the time anywhere in the world and get anxious during British Summer Time ("Daylight Savings Time"). I sorely miss the old KDE ability to have KWorldClock as wallpaper.

The correct term is Daylight Saving time. Time is fascinating. For something that appears simple is quite complex