Hacker News Reader

Comment by paxys | Hacker News Reader

Considering how frequently time zones around the world change, any OS or software that doesn't auto update them from a standard list at this point deserves to break.

View on HN

Sure, but I'd imagine on lots of threads discussing exploits, there are a lot of experts commenting, "Considering how frequently systems are exploited, any system that doesn't require Internet functionality shouldn't be on the Internet".

A system with correctly configured firewalls and other access controls which receives regular updates and zero day patches is still more secure than an offline one.

Not sure how you reached that conclusion. A fully-airgapped system is definitely more secure as long as physical attacks aren’t a threat vector.

Just don't pick up any USB sticks you find in the parking lot

"Auto update from a standard list" - please point me to this standard list. Note - I need to know for a given user at a given location what a millis from epoch equates to in local time, for times that could be before or after this change, so I need timezone conversions AND what dates they were in effect for. I also need some SLAs, and ideally someone I can pay; not much, but enough to feel confident I can get support and/or that it'll be around a decade from now.

You don't need to pay anyone for this – https://www.iana.org/time-zones

The tz database is public domain, and they have HTTP/FTP/rsync APIs. You probably don't even need to implement this yourself, since every modern OS pulls from this already.

Thanks; that is what I was looking for. Last time I had to work in detail with timezones (with the above reqs, plus some others), that didn't exist (based on the date for the RFC).

As to having to/not having to implement this (and rely on the OS) - probably! I just know at the time I last dealt with this, every library I could find packaged their own TZ DB, and they were definitely not standard.

Which RFC? The RFC moving it to IANA in 2012? It's been in development in some way since the 80s [1], the current timezone names in it are from the 90s[2], and it was definitely already the standard timezone definitions when I started using Linux in the 00s.

[1]: http://mm.icann.org/pipermail/tz/1986-November/008946.html

[2]: https://mm.icann.org/pipermail/tz/1993-October/009233.html

Yes, moving it to IANA. Maybe the packaged DBs were 'standard', in a sense, but you couldn't just take a file from one and drop it into another; they were configured or serialized in various ways. Regardless, it meant updating a dependency when things changed; I don't know the state of historical timezone information at the OS level at that time, but I do know none of the libraries I looked at made OS calls.

According to Wikipedia the database was started in 1986 or earlier; it was known as the Olson database.

https://en.wikipedia.org/wiki/Tz_database#History

This is shipped with the OS. On linux usually as a package named tzdata. So you can pay an OS vendor.

You've obviously never worked with clients.

Even digital watches that would last tens of years without battery changes? (and where BT would consume too much energy)

Why would such watches rely on time zone data at all to function correctly?

A lot have auto DST that switches DST automatically. And/or programmed timezones

If they switch automatically then they should also account for timezone changes. Otherwise they should offer a manual update option for the user. If a watch doesn't do either of those then I'd call it broken.

WWVB appears to support permannent disablement of DST [1].

[1] https://en.wikipedia.org/wiki/WWVB#DST_and_leap_second_warni...

Reply on news.ycombinator.com