I have installed Linux Mint first on my Acer Aspire 4930 and then dual-booted with Windows 7.

I always see the correct time on Linux Mint but on booting into Windows the time is shifted back by a few hours, even after resetting the time, on reboot it shows a wrong time again.


  1. Why is this happening?

  2. What can I do about it?


On Windows, the system RTC clock is traditionally kept in local time. In Unix and Linux, it's traditionally kept in UTC, and /etc/localtime is used to indicate the current timezone so that the displayed time is correct.

These two worldviews collide in dual-boot configurations because there's only one RTC. Usually, you tell Linux to assume that the RTC is local time (because Windows can't be told). This varies from one Linux to another, but since Mint is like Ubuntu you can probably set UTC=no in /etc/default/rcS. Then you can set the clock to local time in Windows and Linux will leave it alone after that.

Editor's Note:

That file is not present since Linux Mint 19 (or more precisely since the Ubuntu 18.04 base):

  • 2
    UTC is already set to no, the time difference is still there. – Ballistic Dec 19 '12 at 16:32

Mint 18.2 KDE seems to be immune to the other fixes (including additional ones I found in a search). The files mentioned in aecolley's and error404's answers either no longer exist or seem to no longer be where the setting is referenced, at least in the current KDE version. The command in Julie Pelletier's answer worked for 18.2 Cinnamon but not 18.2 KDE.

After trying half a dozen suggested solutions, the following fixed it for 18.2 KDE. With the correct time displayed, run the following terminal command:

timedatectl set-local-rtc 1 --adjust-system-clock

Source: Tips and Tricks for Linux Mint after Installation [Mint 18 - Cinnamon Edition]

This should also work for Cinnamon as an alternate solution, and I assume other DE's as well.

Editor's Notes:

  • There is no sudo required, run that command as your user.

  • It does persist on reboot, should be permanent.

  • Tested on Linux Mint 19.1 Cinnamon, which is Ubuntu 18.04 based.

  • I confirm, it works on Mint 18.3 Cinnamon. – dchrome Feb 8 '18 at 20:10
  • @Vlastimil, it's been awhile since I did this. My recollection is that sudo isn't required (if it was, I would have included it in the answer, and similar fixes don't refer to sudo either, so I'm pretty sure it isn't). And yes, this persists. – fixer1234 Feb 11 '19 at 7:43
  • @fixer1234 Thanks a lot, mate! You saved my day and I think everyone's :) – LinuxSecurityFreak Feb 17 '19 at 15:04

The most generic way of doing it is with:

hwclock --systohc --localtime

which is persistent across reboots and works on most systems.

  • If your clock currently displays the correct time, then the command you need is indeed hwclock --systohc --localtime, that will set the hardware clock to local time using the value currently displayed by the system. However, if your clock is currently incorrect (i.e. the hardware clock is localtime, but the system adds the offset for your time zone, resulting in an incorrect displayed value), then you need hwclock --hctosys --localtime. – youen Aug 31 '17 at 14:56
  • @youen, I had that situation and your modification just threw the time off in the other direction. The fix for me was to reset the clock to the correct time and then use the command in Julie's answer. – fixer1234 Oct 27 '17 at 5:20
  • @fixer1234 OK, weird. To be honest I didn't try the second command in my comment, since I had already fixed my clock by then. I believe however running any of these commands, and then setting the clock to the correct displayed time, will do the trick (running the first command again was probably not necessary if you had already executed the second one). Glad it worked for you in the end :) – youen Oct 28 '17 at 6:03


This method is buggy in pre-7 versions of Windows, but it resolves the issue on the Windows side of the equation, rather than on the Linux end: you don't have to set Linux to use localtime.

Taken from the most glorious and esteemed Arch Linux Wiki:

One reason users often set the RTC in localtime is to dual boot with Windows (which uses localtime).

However, Windows [can handle the RTC being UTC] with a simple registry fix. It is recommended to configure Windows to use UTC, rather than Linux to use localtime.

Using regedit, add a DWORD value with hexadecimal value 1 to the registry:


You can do this from an Administrator Command Prompt running:

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

Alternatively, create a *.reg file (on the desktop) with the following content and double-click it to import it into registry:

Windows Registry Editor Version 5.00


If the above appears to have no effect, and a 64-bit variant of Windows is being used, using a QWORD value instead of a DWORD value may resolve the issue.

Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.

The hardware clock and system clock time may need to be updated after setting this value. If you are having issues with the offset of the time, try reinstalling tzdata and then setting your time zone again:

# timedatectl set-timezone America/Los_Angeles
  • I've actually been having this very issue on my own Windows machine, but so far I've merely been ignoring it; I shall, however, I'll see if this method works and report my findings. – Alexej Magura Feb 1 '17 at 19:53
  • 1
    It works for me. Many thanks! This way I don' have to modify every Linux installation that's there on my PC. – Lokesh Mar 31 '18 at 14:28

Amend (as root) /etc/timeadj variable from UTC to LOCAL.

This sorted the problem without having to fiddle with regedit on the Windows side.


Run one of these two command which match your local time

timedatectl set-local-rtc 1 --adjust-system-clock


timedatectl set-local-rtc 0 --adjust-system-clock

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.