Hacker News Reader

Comment by thwarted | Hacker News Reader

I never understood why the system-wide timezone database, at least on UNIX-like systems, wasn't used by Java. Why does Java need its own timezone database/database format? Why do I need to install new timezone databases on my Linux system that runs Java? Why can't the Olsen tzinfo files be installed on systems where the OS provider doesn't provide them?

View on HN

Most of the reinvent-the-wheel functionality that Java implements exists to make up for deficiencies in Windows as an OS.

It seems to me that a strength of the Java should be it's ability to only reinvent-the-wheel where necessary, and simply provide a thin compatibility layer over existing wheels on systems that already had them.

I mean, they already have different low-end implementations of "draw this shit onto the screen" for X and Windows..

You have to make implementations in all plataforms to make sure that they behave exactly the same way.

Yes, that is right. So use the tzinfo on systems where it exists, and restrict the more complex implementations of the same interface to systems where it does not (Windows).

But how can you rely on tzinfo and your custom implementation behaving the same? How do you know what version of tzinfo you're running against? What if it changes?

The expensive, costly answer is to rigorously test each version and keep up to date with every change on an external dependency managed by a organisation you have no control over.

The other answer is to just use your package everywhere.

If you have to support common functionality on operating systems ranging from Window XP to Windows 8 (so a 12 year range), and deal with all the bugs within, along with most unix systems, you would start implementing a lot of things yourself.

There was no wheel to reinvent here, the tzinfo data files could have been installed on Windows. They didn't reinvent a wheel, they built a jalopy when there was a perfectly usable high speed rail going to their destination already available.

Really, the tzinfo files could have been distributed with Java, and then linux packages could have removed them and symlinked the paths where java expects them to where they are actually installed.

Indeed. The time zone database is managed by IANA [1] and is the de facto standard of time-zone management, and used by almost every platform (including GNU, iOS/OS X, Android and *BSD) [2] except Windows. The database itself is in the public domain. For Java, it looks like Joda Time implements tz compatibility.

[1] http://www.iana.org/time-zones

[2] http://www.iana.org/time-zones/repository/tz-link.html

So, it isn't supported on Windows? How is that not a deal-breaker for a runtime like Java?

It's supported, of course, just not provided by the OS.

That's one of the reasons Java ships its own; if some systems have different or absent system databases, Java's should still act the same as it does anywhere.

Lawyer-resistance; remember the situation a year or so ago when the tzinfo files were the subject of a patent claim? Oracle's weren't at risk because they have lawyers on retainer.

Oracle's files are based on the tzinfo files, and are just as vulnerable. If anything, more so because Oracle has a lot more money than the tzinfo maintainers.

No, this is about write-once-run-anywhere compatibility as the other responses say.

(Incidentally, it was a copyright claim, not a patent claim, but in this regard they work the same way.)

> Oracle's files are based on the tzinfo files, and are just as vulnerable. If anything, more so because Oracle has a lot more money than the tzinfo maintainers.

Oracle's got enough cheddar to take it to court or settle out-of-court like their business depends on it.

Reply on news.ycombinator.com