Hacker News Reader

Comment by patwolf | Hacker News Reader

Back in '08 when the US dates of DST changed, I was working on a Java-based enterprise software product with a relatively large install base. It suddenly became known to a lot of customers that timezone tables are part of the JRE, and simply updating the OS wasn't enough to get proper time calculations in Java. It was a very stressful time getting customers with many different versions of Java across dozens of platforms properly updated. A lot of customers were running ancient versions of Java that were well past EOL, but we still helped them out.

Needless to say, I'm very happy this might finally happen. I do not, however, envy whoever is now supporting that software. I'm sure there are folks that haven't touched their systems since the last DST change.

View on HN

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.

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)

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

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

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.

Ooof, I remember that. At the time I was writing shipping logistics optimization software for LTL shipping, and many clients were using ancient warehouse inventory systems (lots of data uploads over ftp, etc) that couldn't easily be modified to account for the time change, uh, change. Very painful.

Huh. These days most systems I work with just use a shim into the system timezone tables (I just checked the Qt docs, as that's my preferred way to develop cross-platform apps).

I think the landscape has shifted since the US rules were last changed in 2007. It was awful for pretty much everything that needed to be timezone aware and not just show some local time to a user.

Dates & times were not yet even part of standard C++ (some support started in C++11). Boost got your part of the way there, but it's IANA timezone db support was thin. (It could handle current timezones, but not historical or future). I think MS even support IANA timezone db support on Windows somewhere. Windows' ability to handle historical timezone changes was also pretty limited, and the actually history provided was pretty slim.

While I have no doubt should the DST change be made permanent will cause all sorts of issues with software (I mean, there's plenty of software, especially in embedded that still doesn't take into account the 2007 change), I personally welcome the end of a twice yearly switch. Which direction, I don't really care. I just want the switching to end.

It's probably because Java promises "write once, run anywhere". If you rely on the system timezone tables, you might have a different set of timezones available from one system to another or the rules for the same timezone might differ. And then code would behave differently on different operating systems.

If instead you ship timezone tables with the Java Runtime Environment, then you can promise that (by default) the code will behave the same.

It sucks that it creates extra maintenance burden (and lurking problems people may not be aware of), but that's the price you pay for decoupling.

Yeah, when I read about the Java behavior I figured it was to get cross-platform consistency. All that I can say is that I concluded that the opposite approach (applications should be written to handle what the system tables provide through a shim API like Qt provides) makes more sense. I noticed this recently when I had to install some CA certs into my JRE when a java app didn't use the system ones.

I remember this too. The major difference is things auto-update more frequently, and people have higher bandwidth connections. So it's less of a problem that 14 years ago, luckily.

Reply on news.ycombinator.com