Hacker News Reader

Comment by ohyes | Hacker News Reader

I'm against this because it will require software changes.

You mean you would need to update your time zone database, just like you already do on a regular basis?

ah, I guess I'm the only one who makes things that are air-gapped and don't take updates on the regular. It's hard being in my own little bubble.

Air-gapped and automatically handles DST correctly seems like a small niche to me, but I'd be happy to be proven wrong.

Anything safety critical with strict reporting requirements (clock must be correct so logs are accurate).

Honestly, most things that need to be air-gapped also need to have correct clocks. Most other things also need to have correct clocks / time, but it is easier to use available stuff in that situation.

industrial control systems, medical devices, transportation systems, important, critical infrastructure stuff.

Okay, I have to ask: shouldn’t a system like this use TAI or at least UTC? If you are air gapped and really need accurate time, you at least have to deal with leap seconds. Even if a one-second error doesn’t bother you, there’s an entire two-hour interval when DST ends in which the local time is ambiguous. Or do these systems try to do the right thing by distinguishing 2:30 AM PST from 2:30 AM PDT?

Sure, internally you will store it in something less ambiguous... but you still have to display the correct time & timezone and be able to set the time correctly (and note when the clock has been set). Time is generally set by humans according to their local time. So you do need to differentiate PST from PDT, even if something like that is kind of an edge case..

You probably have an acceptable time zone you could switch to, assuming you don't need exactly correctly formatted times during the crossover, and that you're ok with slightly unusual timezones/abbreviations.

The TZ file changes multiple times a year already. It won't be a big deal.

Reply on news.ycombinator.com