I feel like other things would have misbehaved if the power frequency was too low. And I’d expect the RTC to run well while power is on, and fail to accumulate time while power is off, but still remember the time at power off.
None of what I said above explains what we are seeing with our eyes though.
tal@olio.cafe 5 weeks ago
I don't think that the grid frequency is used for PC timekeeping. You have internal timekeeping circuits. I don't think that there's any cable over which a time protocol flows from the PSU to the motherboard.
tal@olio.cafe 5 weeks ago
I'd also bet against the CMOS battery, if the pre-reboot logs were off by 10 days.
The CMOS battery is used to maintain the clock when the PC is powered off. But he has a discrepancy between current time and pre-reboot logs. He shouldn't see that if the clock only got messed up during the power loss.
I'd think that the time was off by 10 days prior to power loss.
I don't know why it'd be off by 10 days. I don't know uptime of the system, but that seems like an implausible amount of drift for a PC RTC, from what I see online as lilely RTC drift.
It might be that somehow, the system was set up to use some other time source, and that was off.
It looks like chrony is using the Debian NTP pool at boot, though, and I donpt know why it'd change.
Can DHCP serve an NTP server, maybe?
kagis
This says that it can, and at least when the comment was written, 12 years ago, Linux used it.
https://superuser.com/questions/656695/which-clients-accept-dhcp-option-42-to-configure-their-ntp-servers
My Debian trixie system hhas the ISC DHCP client installed in 2025, so might still be a factor. Maybe a consumer broadband router on your network was configured to tell the Proxmox box to use it as a NTP server or something? I mean, bit of a long shot, but nothing else that would change the NTP time source immediately comes to mind, unless you changed NTP config and didn't restart chrony, and the power loss did it.