I think this is a good place to ask this; so, this is my problem:
The system is supposed to boot with the correct time for my timezone, and the time in the firmware should be the same. That was the case when I was on NixOS 24.11.
However, since I upgraded from NixOS 24.11 to 25.05, the system’s time is now always [ firmware time - 3 hours ] on boot, then updates to the correct time after some time (when I have an Internet connection). It’s like the timezone time offset is based on my hardware clock time, which is really weird. I’ve been thinking that it was a bug, but as I haven’t seen anyone else talk about this, I’m not sure. I even did a clean installation and it still happens either way. I’ve tried messing with time.hardwareClockInLocalTime and I think some other options, but nothing helped. Also, if I keep rebooting before it gets corrected, it keeps going back 3 hours each boot.
I guess it’s not very big of a deal, but it kind of annoys me a bit.
I’m not dual booting Windows. NixOS is the only system in my SSD. The problem happens even with a default config. I used the latest 25.05 graphical ISO and installed choosing xfce, [ erase disk; swap (“no Hibernate”) ] and I chose timezone America/Montevideo to test it. The only thing I changed was time.hardwareClockInLocalTime to true;.
If you set that, and your system is driven by Linux, you would expect exactly the clock drift you’re seeing because Linux will not update the hardware clock with local time when the time sync happens.
I’m not sure what you mean. From what I’ve seen, that made the hardware clock get updated to the same time as the time on my Linux system, which made them consistent. What’s strange is that this problem wasn’t happening in previous stable versions. Both clocks were synced (with said option set to true); so I’m not sure what changed and if I really need to use some sort of workaround. I used that option and it seemed to fix the clock desync problem a while ago, so why is it suddenly behaving this way in the new stable version?
The correct setup for Linux is hwclock in UTC. The only reason to not do that is if you dual boot windows. It is not a work around to set the system clock to UTC.
When did you change this? It sounds like this is a change you made vs previous installations.
It’s what I’ve been using since soon after I started using NixOS. What I meant was I set it in the configuration of that newly installed system, because that’s what I normally use on my main system and it seemed to not give me any problems before.
Well, that option is certainly not the correct one to use on Linux, unless you dual-boot windows. That said, the option looks to fix the main time writing services too. Did you switch to a non-chrony ntp service?
I’ve checked the blame, functionality around the hwclock hasn’t changed in half a decade. Hard to tell what exactly the cause is here.
So, if I were to dual boot Windows, this would still be a problem either way, right? I do sometimes use Windows in a separate SSD (and Windows refuses to update the time for some reason) which would have the wrong time with that option set to false because the hardware clock would be wrong. What would be the best approach here?
I just used the default config (+ that option setting I mentioned) from that quick test install I mentioned earlier, and it had the same result as the problem in my main system.
It would be really helpful if you stop drip-feeding information. You probably had things working correctly if you booted windows at all because windows wants to the clock to be local time. The hardware is shared, it doesn’t matter if the OS is on a separate disk. There is a reason people keep mentioning this setting in relation to dual booting and it’s not because we like asking pointless questions lol For instance @TLATER has gone on a what I would estimate at this point to be a goose chase trying git-blame potentially interesting parts of the OS to see if settings have evolved based on you previously stating that you don’t dual boot.
I’m sorry if I wasn’t very helpful, I was just tired of this happening and looking for a good answer and decided to ask for help on something that didn’t seem to be caused by me and that seemed to be a bug with the newest versions. It still seems like a bug to me, but perhaps I should just try something different. Thanks for your time, though.
I am still interested in seeing you get to a solution Did you go through the arch wiki page? I really don’t think there is a bug. I think you’ve gotten your wires crossed and that’s fine. I think you have two choices:
Yes, that does seem to be a solution. I wanted to have the hardware clock and system clock be synced, but I guess it doesn’t really matter much. The only time it’s relevant is when I’m in the firmware setup (which I can just remember to subtract a few a hours, I guess). I just like everything being consistent; but if there’s not much that can be done without breaking something else, I’ll just consider it a solution.
Apologies in advance if this comes across as pernickety I promise it is offered with the goal of sharing:
The clocks are in sync. They are both referencing the same point on the real timeline and rendering it in different ways.
The RTC on your PC doesn’t know anything about timezones, it expects to be a reference to UTC, it ticks upwards monotonically. In order for it to respect DST the computer has to boot, figure out the the time on the RTC is wrong with respect to local time by querying ntp, then trimming the RTC. That’s crazy! What I am really trying to say is that if you power off your computer the night before a DST shift, then boot directly into EFI, then the time will be wrong on the firmware screen.
From a “you want your software to not have bugs” perspective codepaths that derive LocalTime from UTC are trivial (it’s a one way mapping) whereas the other way around is significantly harder due to discontinuities induced by DST. Not all local times even exist! If it weren’t under NDA I would insert a link to a signed-distance function I wrote to calculate the next time a local time occurs in a given timezone given a reference time (UTC). Truly heinous.
Basically it’s nice to want things, but in this case the thing you want is kind of impossible, unless you want your efi firmware to also be packing a copy of the tzdb, and in that case it would still make sense for the rtc to be UTC s.t. the firmware could derive the correct local time from it. Time is hard.
EDIT: Ok so apparently EFI does have timezone aware services. TIL. I guess at some point I’m going to have to reboot and poke around.
For instance