May seem like this is a Windows question, but since I only have this problem as soon as I installed Linux Mint 17, and the Windows forums probably don't deal with Linux, I thought I'd post it here, since the average Linux user generally know more then Windows.

When I boot to Linux, I use it for a while then if I need to use Windows, when I boot back into Windows 10, my date and time are all way off.

I go in and set it. It will work good. Boot into Linux, boot back into Windows, Windows date and time are way off.

Ever herd of that? What could be causing it? All the years of Windows, I never had this problem until I installed Linux.

Thank you,

Chris.

I have the same problem with my Linux systems on my Desktop but I'm not running Windows.

I have Slackware on a 500 GB HDD by itself.
When I boot into Linux Mint Mate on the other 1 TB HDD with Korora on it all is well until I boot back into Slackware and I have to consistently fix the time.

At first I thought it was a BIOS clock issue. I checked on the BIOS clock and the time is right so I don't get what is generating this issue.
I haven't found a fix for this yet but maybe other members here have?

I suspect there is some kind of conflict between the hardware clock and the sytem or BIOS clock.

-::-If I find a fix I'll post it for you.-::-

Your distro should allow you to set whether it keeps time in UTC or local time. In Slackware this is set with /sbin/timeconfig.

Windows keeps time in local time.

Thanks dugan but I have already tried timeconfig several times. No dice, it doesn't stick.
I have it set to UTC and it still gives me issues.

The only thing that helps are the commands I have to run in my blog about fixing the clock in Slackware.

The problem is that the two (or more) OSs are configured differently. This is commonly a problem when dual booting GNU/Linux with another OS, but can also occur when booting different instances of GNU/Linux, as Ztcoracat has found.

Here is what happens...

There is a hardware clock, or BIOS clock, which keeps time when the system is powered off.

When the OS is booted it gets its starting time and date from the hardware clock, but it keeps time separately using kernel timers (i.e. a software clock), also called the system clock.

While running, most GNU/Linux distros will sync the system clock with a network clock using ntpd and the system configuration, so it is very accurate.

When the system shuts down, it updates the hardware clock from the now updated system software clock.

Where problems occur is when one OS is configured for a different time zone, or when it thinks the hardware clock is local time when it is really UTC. If the other OS sets the hardware clock to local time (adjusted for time zone) but the current OS thinks it is UTC, then when it starts it loads the time and adjusts for local time zone, and syncs with ntpd. Then when it shuts down it writes the adjusted time back to the hardware clock as UTC... so when the other OS boots it loads UTC but thinks it is local time!

The fix is simply to tell all OSs that the hardware clock is either UTC or local time AND that they are in the same local time zone. I always set my hardware clock to UTC.

Window$ was very ignorant of time and date last time I used it (16 years ago), but I expect it now uses NTP too, or not...

Anyway, on Slackware run timeconfig as root to set the hardware clock and local time zones. On other distros use whatever facilities they provide. The important thing is that ALL OSs that boot the same hardware agree on the time zone of the hardware clock - UTC or local.

*** UPDATE: As dugan notes, Window$ always assumed local time when I last used it, so GNU/Linux was forced to set hardware clock to local time too. If that is indeed still the same then you will have to let time-challenged Window$ have its way and set your Linuces to local TZ as well.

1 members found this post helpful.

Thanks astrogeek-

I'll try timeconfig as root again and post if it works this time.

Define way off.

If the time is off by your UTC/local time offset then it is a BIOS windows / linux setting. The BIOS clock and the setting in /etc/adjtime must match (UTC vs localtime). Typically windows would expect the BIOS clock to be set to local time but can be changed via a registry setting if running > XP (If I remember correctly). I keep the BIOS at localtime just to make sure that both OSs stay happy.

1 members found this post helpful.

Another thing to remember is that when you set one OS, then boot to the other to set it too, it is going to initially get and adjust for the boot-time settings - again - before you change things with timeconfig. This may mess up the hardware clock again for the next boot!

So boot into each one and change their configurations. Then when they all agree on the configs, reset the hardware clock to the actual current time according to those settings.

In Slackware (and other Linuces I suppose), you can force the hardware clock like this...

1 members found this post helpful.

I suspect this may be the root of the issue:

Windows by default sets itself to local time. Most Linux distros by default set themselves to UTC then use the timezone setting to display local time. (Many Linux distros give you the option to choose between UTC and local time during install.)

As time settings tend to be saved to BIOS at time of shutdown, this means booting from one side of the computer to the other will change the BIOS (or equivalent) setting during shutdown, which will then affect the time on the other side of the computer during boot up.

I have encountered this and the only solution I've found it to ensure that both sides of the dual boot are set to the same time settings--not the clock settings, the underlying time settings.

1 members found this post helpful.

Even if both OSes are set to use local time, this issue can also cause a problem if a local daylight saving time change occurs. I have found that that is best to first boot Windows after a daylight saving time change occurs, as Windows will automatically change the hardware clock. After that, boot Linux and it will happily accept the updated hardware clock time. If you reverse the order, the hardware clock will be updated twice, once when Linux shuts down and then again when Windows boots.

I have set my Windows install to use UTC hardware clock which solves the issue completely. The link says it is for Windows 7 but I can confirm it works with Windows 10 also.

If I boot to Windows at 1pm, it may say 2:30am. I think the day is off but I can't remember.

Chris.

The CMOS battery might need to be replaced.

It's very important to pay attention to the times, write them down if you have to. If Windows claims it's 2:30 when the actual time is 1:00 (IE: the minutes are different), then that is a VERY different problem to LT vs UTC as is being discussed here. If the minutes are the same but the hours are different, then it could be LT vs UTC. You'd need to tell us what time zone you're in and what the EXACT times each OS is telling you in order to verify if that's the problem. Just a quick, "At 1:23 pm the output of `date` in Linux was XXX and the output of `date -u` in Linux was YYY, I then rebooted to Windows at 1:25pm and it claimed the time/date was ZZZ".

Running 'timeconfig' as root choosing 'UTC' or 'local time' and rebooting the clock was still incorrect.

I too like allend noticed the problem with the clock as soon as daylight savings time arrived. (spring forward)

The closest the clock was to right was running timeconfig and setting it to local time and than the clock was an hour off.
It's actually 1:00 p.m. but with local time set the clock after a reboot said 12:00 p.m.

The only thing for me that does work is to run these cmd's to fix the clock in Slackware.
Setting the clock's first on the other 2 Linux distro's on a separate drive made no difference and a fresh reboot into Slack the clock was still wrong. For now; I'm glad that the cmd's I posted work.-