Hacker News Reader

Comment by moomoo11 | Hacker News Reader

Interesting. Reminds me when the battle.net client seemed to bug out after I switch OS from deb to win11 and somehow my clock is always messed up. I have to fix my time (sync it again in settings app) otherwise it seems games don’t load.

Maybe they’re checking my location against time and IP? This was a while ago when I was trying out wow classic.

View on HN

Your clock messes up because your Debian and Windows are disagreeing on whether your Real Time Clock should be set in local time (Windows) or UTC time (Linux).

fix: timedatectl set-local-rtc 1

Alternatively, tell Windows the RTC is in UTC: https://wiki.archlinux.org/title/System_time#UTC_in_Microsof...

That registry flag is routinely broken in various versions of Windows and hotpatches to the same version. It's not wise to rely on it.

That seems like the kind of thing that shouldn't be broken all the time given how common of an issues this is. Perhaps it's not wise to rely on windows.

All my home PC's dual booting linux/windows (3 I think) are set to think the hardware clock is UTC. Never had a problem, did that at least 5 years ago.

Now relying on that in a production environment ...

Agreed. Don't bother trying to make Windows give Linux the time of day (pun totally intended), it never works, that's probably by design. Just give up and make Linux accommodate the Windows style system clock, has almost no issues.

And that explains why I've had issues trying to use that reg flag Thanks for the info!

Strange, I've never had trouble with it on win10 + Linux. Maybe there's a (third party) driver that messes with the RTC for some reason that doesn't always activate?

Maybe I shouldn't be too surprised that Microsoft's support is broken.

is there any known nasty consequences from setting that? Like things I should expect

The local time can be ambiguous during a daylight savings time transition. That is, if you use local time in the RTC, and turn your computer on during that ambiguous hour, it will not know which offset should be applied. I believe Windows "solves" that by storing state in the registry, which means that dual-booting with local time in the RTC might in some cases lead to the daylight savings time transition being applied twice (whenever the other operating system has already corrected the RTC clock, but Windows believes the correction hasn't been applied yet). Using UTC (or any local timezone without daylight savings time) avoids that issue, since there's no repeated hour.

probably not a problem for me given I'm in a jurisdiction without DST! Thanks for sharing that information

Reply on news.ycombinator.com