0

Did a fresh Fedora 32 install by erasing existing Windows 10 Pro installation completely(No dual boot here). After installation, the display time is acting weird.

My local timezone is IST. That is, +5:30 from UTC. At 01:00PM, my clock shows time as 6:30PM. When I inspected the issue using timedatectl I saw that

Real Clock Time: 13:00 - IST UTC: 13:00 - IST Local Time - IST+05:30

$ timedatectl
     Local time: Thu 2020-07-30 18:30:40 IST
 Universal time: Thu 2020-07-30 13:00:40 UTC
       RTC time: Thu 2020-07-30 13:00:40
      Time zone: Asia/Kolkata (IST, +0530)  
 System clock synchronized: no                         
    NTP service: inactive                   
RTC in local TZ: no

How to correct it?

codeandcloud
  • 101

1 Answers1

1

On your machine, you got a hardwareclock (RTC). Windows and Debian disagree, wheter that clock should be on UTC (Debian's oppinion) or on LT (Windows oppinion).

You should choose waht time on your hardwareclock should be and change it on the OS.

RTC is LT

You have to change Debians setting. Run this command as root.

# timedatectl set-local-rtc 1

RTC is UTC

I personally prefere that, because the clock never hase to jump, when you change the timezone for travelling or when you cnage to wintertime.

But you have to change settings in Windows. So you need the cmd running as administrator:

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

After you have fixed your settings, you can sync the time and the time will work fine.

Source: ArchWiki

Boba Fit
  • 119
  • It's easy to reach for the canned "You haven't used UTC for your hardware RTC." answer, but in this case the question outright tells us that the hardware RTC is in UTC. The real problem here is that the questioner hasn't noticed an important paragraph in the ntpdate manual, and an important setting in the ntpd manual that applies to a clock that is 5.5 hours off. This WWW site's general NTP Q&A already answers this. – JdeBP Jul 30 '20 at 20:10
  • @JdeBP: The question is (IMHO) unclear, and you and I are interpreting it differently. The problem is that the OP doesn’t say what time it really* is* when he runs the timedatectl command. Yes, it shows that the RTC time is set to the same value that is displayed as UTC. But the text says “Indian Standard Time (IST) is being incorrectly shown as Universal Time (UTC).” I interpret this to mean that he ran the command at 13:15 IST (local time), and so the RTC is set to local time (and the command is displaying local time incorrectly). – G-Man Says 'Reinstate Monica' Jul 30 '20 at 20:47
  • I will re-write the question. I am basically a Microsoft stack developer and a noob with linux. Exploring .NET Core runtime. – codeandcloud Jul 31 '20 at 03:02
  • The big clue, G-Man, was that the question was posted roughly half an hour after the local time given in (the original version of) the question. (-: The questioner has done everything right, set the hardware RTC to be interpreted as UTC and run an NTP client. The NTP client simply did not "fetch the correct UTC", which is in the question title and which is exactly what is dealt with by the general NTP Q&A aforementioned. UTC in the hardware clock is off by 5.5 hours (for obvious reasons) and neither ntpd nor ntpdate were willing to fix it by fetching the correct UTC. – JdeBP Jul 31 '20 at 13:36