Time problem in dual boot

All Gurus once were Newbies
Forum rules
There are no such things as "stupid" questions. However if you think your question is a bit stupid, then this is the right place for you to post it. Please stick to easy to-the-point questions that you feel people can answer fast. For long and complicated questions prefer the other forums within the support section.
Before you post please read how to get help
Post Reply
rezza
Level 1
Level 1
Posts: 44
Joined: Sat Mar 16, 2019 4:42 am

Time problem in dual boot

Post by rezza » Thu May 02, 2019 10:53 am

Hi
I installed linux mint 19.1 recently beside the windows .
Every time when i boot the windows , windows time is incorrect and i have to set again .
but linux time always correct .
what can i do ?

pbear
Level 6
Level 6
Posts: 1438
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

Re: Time problem in dual boot

Post by pbear » Thu May 02, 2019 12:06 pm

The problem is that Windows and Linux use different methods for syncing time. You can resolve the inconsistency either way, but it's easier to conform Mint to Windows, so that's what I do. Simple. Open Terminal and run the following command (use copy and paste):

Code: Select all

timedatectl set-local-rtc 1
Done. Can be confirmed with timedatectl status and reverted with timedatectl set-local-rtc 0.
Don‘t worry about daylight savings time. Windows will take care of that.
Time flies like an arrow. Fruit flies like a banana.
If your problem has been solved, please edit the thread title.

rene
Level 10
Level 10
Posts: 3392
Joined: Sun Mar 27, 2016 6:58 pm

Re: Time problem in dual boot

Post by rene » Thu May 02, 2019 12:49 pm

Careful though if you e.g. transfer photo's from a camera's SD-card to the computer under Linux after setting localtime like that; you will find that timestamps on files from a FAT-formatted source will from that point on show an offset equal to your own offset from UTC...

pbear
Level 6
Level 6
Posts: 1438
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

Re: Time problem in dual boot

Post by pbear » Fri May 03, 2019 12:02 am

rene wrote:
Thu May 02, 2019 12:49 pm
Careful though if you e.g. transfer photo's from a camera's SD-card to the computer under Linux after setting localtime like that; you will find that timestamps on files from a FAT-formatted source will from that point on show an offset equal to your own offset from UTC...
Frankly, that sounds like a bug, or at least a very poor design decision. Why is Linux changing the timestamps in the first place? Or are you talking about the "last accessed" timestamp, which wouldn't be a big deal either way. Also, do you know whether there's a corresponding problem if one configures Windows to use UTC, i.e., does that result in modified timestamps if transferring photos from an SD card in Windows?
Time flies like an arrow. Fruit flies like a banana.
If your problem has been solved, please edit the thread title.

rene
Level 10
Level 10
Posts: 3392
Joined: Sun Mar 27, 2016 6:58 pm

Re: Time problem in dual boot

Post by rene » Fri May 03, 2019 6:14 am

It's a bug "of sorts" but not one that will be "fixed" at some point...

The main issue is that RTC on localtime is a technically poor choice. In light of DST which implies possibility of time going backwards, a definite no-no for devices such as computers that need a monotonic time source, and/but similarly in the "laptop on a plane sense" in which same may happen even frequently. RTC on UTC conversely just keeps on being (as) right (as it started out as).

As a result MacOS and by recommendation most UNIX systems keep the RTC on UTC, and as a result of that the systemd MacOS copy-bunnies will since version 216 of 2014 not sync back time to the kernel at startup if the RTC is on localtime; will keep the kernel uninformed of local timezone, which is to say it assumes said zone to be UTC. Frankly I applaud them for it --- and I like bunnies; don't get me wrong... --- but what this turns out to mean is that timestamps on filesystems such as FAT that do not themselves indicate offset from UTC are assumed to be in UTC.

This then means that, say, a picture taken in timezone UTC+N and stored by the camera on a VFAT-formatted SD-card is upon inserting said SD-card into a systemd Linux system assumed to have been taken N hours later than it actually was, with said bad assumption cemented into the timestamp for ever more upon in fact copying the photo to a local filesystem that does use UTC timestamps. Assuming of course that timestamps are kept over the copy in the first place, but we've seen enough threads even here on the forum concerning this issue that it seems many people in fact like to do that.

Certainly a filesystem not using UTC timestamps is the original bug here, even though in the case of FAT that's historic and not globally fixable after the fact. On Linux you can actually mount a FAT filesystem specifying the time_offset=minutes mount option which sort of works for static systems (and static mounts, i.e., when you in fact have the possibility to supply an option) but best make sure for example that your camera didn't visit more than the one timezone you try to compensate for. DST we shall not even go into...

I'm not a mobile-tech person and have no oversight over how relevant the issue still is. exFAT does have support for UTC timestamps and/or indication of offset from UTC and I've frankly no idea if that's actually globally used and/or whether or not anything but exFAT can already be considered or declared definitively obsolete. As such, yes, "a bug of sorts", but one with a bit of history behind it.

I could not definitively tell you if conversely Windows has any issues with UTC other than it not being the default and a pain in the butt to set, since this and similar issues has had me move the single Windows system I keep around for some gaming by myself and, mostly, others (Windows 7) to its own dedicated system. I won't let Windows ever again near a serious system. As far as I'm aware it has no issue such as opposite FAT-timestamp behaviour but I can't then promise said awareness to be very aware.
Last edited by rene on Fri May 03, 2019 7:59 am, edited 1 time in total.

User avatar
I2k4
Level 5
Level 5
Posts: 582
Joined: Thu Feb 02, 2012 8:33 pm

Re: Time problem in dual boot

Post by I2k4 » Fri May 03, 2019 7:15 am

rezza wrote:
Thu May 02, 2019 10:53 am
Hi
I installed linux mint 19.1 recently beside the windows .
Every time when i boot the windows , windows time is incorrect and i have to set again .
but linux time always correct .
what can i do ?
A common problem fixable on the Windows side. You don't specify.the Windows version, but this works on my Win 7 boots:

https://lifehacker.com/fix-incorrect-cl ... ti-5742148
TRUST BUT VERIFY any advice from anybody, including me. M18.3 XFCE (Dell 1520) 64 bit. Dual booting M19.1 XFCE / W7 (Acer netbook) and M19.1 Cinnamon / W7 (Lenovo desktop) 64 bit. Persistent live USB pretesting M19.2 Cinnamon and XFCE.

pbear
Level 6
Level 6
Posts: 1438
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

Re: Time problem in dual boot

Post by pbear » Fri May 03, 2019 11:24 am

rene wrote:
Fri May 03, 2019 6:14 am
It's a bug "of sorts" but not one that will be "fixed" at some point...
Thanks for the explanation. Bear in mind, for most newbies," Linux will mess up my timestamps" is a reason not to bother. If they're doing dual boot, Windows generally will be the main system. Nor will they view hacking the registry as a trivial exercise. And, besides, switching Windows to UTC has it own knock-on effects. Anyhoo, this comes up often enough that I'm working on a FAQ-like answer. And agree it should include disclosures. The trick is making them simultaneously adequate but not unduly alarming. And, of course, the disclosures should run both ways.
Time flies like an arrow. Fruit flies like a banana.
If your problem has been solved, please edit the thread title.

rene
Level 10
Level 10
Posts: 3392
Joined: Sun Mar 27, 2016 6:58 pm

Re: Time problem in dual boot

Post by rene » Fri May 03, 2019 3:36 pm

I'm more into RTC on UTC than into newbies but I suppose you may in said FAQ like to note that you can keep RTC on localtime and kludge around the FAT timestamp issue with a mount helper. You'd for example create a script /sbin/mount.msdos containing

Code: Select all

#!/bin/sh
exec mount -i -o time_offset=$(date +%:z | awk -F: '{ print 60*$1+$2 }') "$@"
and make sure it's executable with sudo chmod +x /sbin/mount.msdos and link sudo ln -s mount.msdos /sbin/mount.umsdos and sudo ln -s mount.msdos /sbin/mount.vfat. The latter type is what FAT filesystems are mounted as by default, but this is also applicable to msdos and umsdos so let us be complete.

Note for those who'd care: rather than a mount helper a udev rule would be more elegant but as of the date of writing this comment this is not in fact possible: https://github.com/storaged-project/udisks/issues/609. Currently udisks hard-codes options without paying attention to e.g. environment as settable from a udev rule.

mediclaser
Level 4
Level 4
Posts: 361
Joined: Tue Mar 20, 2018 2:28 pm

Re: Time problem in dual boot

Post by mediclaser » Fri May 03, 2019 7:57 pm

I do not use UTC on my Linux machines because none of my photo/video cameras understand UTC. It would have been good if Linux could adjust date stamp of uploaded media files from devices which do not use UTC.
If you're looking for a greener Linux pasture, you won't find any that is greener than Linux Mint. ;)

rezza
Level 1
Level 1
Posts: 44
Joined: Sat Mar 16, 2019 4:42 am

Re: Time problem in dual boot

Post by rezza » Sat May 04, 2019 6:40 am

Hi
I ran timedatectl set-local-rtc 1 command in terminal ,but problem wasn't solved !

User avatar
GS3
Level 5
Level 5
Posts: 569
Joined: Fri Jan 06, 2017 7:51 am

Re: Time problem in dual boot

Post by GS3 » Sat May 04, 2019 7:06 am

Previous thread: viewtopic.php?t=276009

Computers communicate all over the world and need to have a common reference.

People need to understand that there is only one Universal Time (UT) and using any other local time without specifying the time difference with UT only creates problems.

You can have a computer on UT or you can have it on local time but the timestamp must specify the difference between local time and UT, otherwise it is worthless.

I have run into a lot of problems with this issue because many devices and software do not implement this correctly. I have had to spend time correcting this in cameras, GPS, etc. and it is a pain.
HP Compaq Elite 8300 CMT - Linux Mint 18.2 Sonya - Kernel 4.4.0-148-generic X64 - Cinnamon 3.4.4 - Nemo

rezza
Level 1
Level 1
Posts: 44
Joined: Sat Mar 16, 2019 4:42 am

Re: Time problem in dual boot

Post by rezza » Sat May 04, 2019 7:19 am

Sorry, that command worked perfectly .
I had a mistake .
thanks .

brancalessio
Level 1
Level 1
Posts: 31
Joined: Fri Jul 24, 2015 4:59 am

Re: Time problem in dual boot

Post by brancalessio » Fri Aug 16, 2019 9:12 am

Hello everyone!

I write a new post in this thread and do not open a new thread. There are already several similar threads, I do not want a new one.

I have of course the same problem.

Dual boot: Windows 10 (completely standard settings) and Linux Mint 19.2 (also standard settings). I seems that the BIOS clock is set by Windows 10 in local time at shutdown, and by Mint in UTC at shutdown.

Let me also say that the same computer was previously dual boot with the same Windows 10 and Linux Mint 17.2 and I never had such problem (maybe just at the summer time begin or end). Let me also say that another computer of mine runs Windows 7 (completely standard settings) and Linux Mint 17.3 (also standard settings): again none of such problems.

In all described cases, the output of timedatectl status contains RTC in local TZ: no

What did change from Linux Mint 17.x to 19.2? I cannot find the answer in this post or in others. Is the difference a choice of (let's say) the command timedatectl or in the shutdown script (Linux Mint 17.x uses Upstart, Linux Mint 19.2 uses systemd).

Thank you for your answers!

viewtopic.php?f=47&t=289090
viewtopic.php?f=46&t=286585
viewtopic.php?f=29&t=268363
viewtopic.php?f=90&t=276623
viewtopic.php?f=47&t=274450

rene
Level 10
Level 10
Posts: 3392
Joined: Sun Mar 27, 2016 6:58 pm

Re: Time problem in dual boot

Post by rene » Fri Aug 16, 2019 10:24 am

brancalessio wrote:
Fri Aug 16, 2019 9:12 am
What did change from Linux Mint 17.x to 19.2?
systemd is rather explicit about deprecating localtime; on 17.x it was on Mint the default (at least when the installer detected a Windows dual boot; not sure any more about that part) and was controlled by a variable in an init script rather than through timedatectl.

I am not sure what the eventual question is. You mention having as far as Linux is concerned RTC on UTC ("RTC in local TZ: no"). I.e., as this thread says, try timedatectl set-local-rtc 1 to have Linux use localtime as well as the easiest workaround -- certainly when you're not using e.g. a camera with a VFAT-formatted SD-card as per my above reply.

brancalessio
Level 1
Level 1
Posts: 31
Joined: Fri Jul 24, 2015 4:59 am

Re: Time problem in dual boot

Post by brancalessio » Fri Aug 16, 2019 3:58 pm

rene wrote:
Fri Aug 16, 2019 10:24 am
brancalessio wrote:
Fri Aug 16, 2019 9:12 am
What did change from Linux Mint 17.x to 19.2?
systemd is rather explicit about deprecating localtime; on 17.x it was on Mint the default (at least when the installer detected a Windows dual boot; not sure any more about that part) and was controlled by a variable in an init script rather than through timedatectl.

I am not sure what the eventual question is. You mention having as far as Linux is concerned RTC on UTC ("RTC in local TZ: no"). I.e., as this thread says, try timedatectl set-local-rtc 1 to have Linux use localtime as well as the easiest workaround -- certainly when you're not using e.g. a camera with a VFAT-formatted SD-card as per my above reply.
My question was more a curiosity about what happened from version 17.x to 19.x to change the behaviour. I should not have problems with FAT filesystem and cameras.

I will try your timedatectl set-local-rtc 1 suggestion. Another possible workaround could be also to force Windows to synchronize with its time server at every boot.

In general I could live with this time drift (even though a little bit annoying...), but I wonder, could this time drift affect applications like Dropbox?

rene
Level 10
Level 10
Posts: 3392
Joined: Sun Mar 27, 2016 6:58 pm

Re: Time problem in dual boot

Post by rene » Fri Aug 16, 2019 10:23 pm

You shouldn't pursue any other option than either configuring Linux to treat the RTC as being in localtime rather than UTC (i.e., as per above) or conversely configuring Windows to treat the RTC as being in UTC rather than localtime. Latter as preferred from a sanity standpoint as per above replies, but actually doing so might still be a problem. We're after all still dealing with Microsoft: any anticompetitive measure is better than none...

Post Reply

Return to “Newbie Questions”