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?

Improve this question
3
  • This is already covered at unix.stackexchange.com/q/91792/5132 , a general Q&A for these situations. Commented Jul 30, 2020 at 20:10
  • It's not a good idea to edit out of the question your main point, which was that you ran ntpd and ntpdate and they did not "fetch correct UTC". Commented Jul 31, 2020 at 13:36
  • ok will update. Commented Jul 31, 2020 at 15:10

1 Answer 1

Reset to default
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

Improve this answer
4
  • 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. Commented Jul 30, 2020 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). Commented Jul 30, 2020 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. Commented Jul 31, 2020 at 3: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. Commented Jul 31, 2020 at 13:36

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.