3 ms·
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
by adrianmonk 5y ago
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.
- dekhn 5y agoYeah, 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.