Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Many RTCs decide not to tick anymore when that happens.

Of course I laughed when I read that, but then I realized I was interpreting that line to mean "it declares shenanigans and stops reporting time so you realize something broke."

Just wanted to clarify - do you mean the above, or "of course software cannot kill hardware!!1" "won't tick anymore"?



Yeah, IIRC it really stopped ticking (until you write a valid value at which point it would resume).

Note that it doesn't stop reporting the time in this condition it will just give you back all the garbage fields that you wrote before. So an interesting thing happens when the system tries to transform that into a UTC wall clock basis and it usually ends up with a really wild interpretation of the date (decades/centuries off, similar to the problem described in TFA).


> Yeah, IIRC it really stopped ticking (until you write a valid value at which point it would resume).

Ah, okay then. Good to know I can't accidentally thousands of dedicated servers :P (ie, via NTP MITM, writing to hw RTC...)

> Note that it doesn't stop reporting the time in this condition it will just give you back all the garbage fields that you wrote before.

I don't know why I didn't remember this last night: Linux uses the RTC as a poor-man's NVRAM that will persist across a reboot. Provides <24 bits of data to work with (yay! ...not). https://wiki.ubuntu.com/DebuggingKernelSuspend, useful info in https://github.com/torvalds/linux/blob/e34bac726d27056081d02...

> So an interesting thing happens when the system tries to transform that into a UTC wall clock basis and it usually ends up with a really wild interpretation of the date (decades/centuries off, similar to the problem described in TFA).

Right.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: