3 ms·

Is there any talk in the Java world of decoupling the runtime from the tzdata distribution? AFAIK, it is still coupled together and requires a tool to update th

Is there any talk in the Java world of decoupling the runtime from the tzdata distribution? AFAIK, it is still coupled together and requires a tool to update the data files or you have to apply JRE updates (which must be published in time). The tzdata updates usually 10+ times a year and a company actually operating in most of those zones needs to have a straightforward way to push out updates not only across all production systems, but across all production languages. This usually makes solutions that "transpile" the binary data into native source or otherwise embed the data into resources somewhere much more operationally expensive. Native solutions (e.g., pytz in Python) that can be pointed to an directory to pick up the tzdata binary files are a good middle-ground, as it decouples the logic from the data. Operationally, you need to be able to deploy the updates very quickly. Every year there are data updates that occur a few days before the DST change. If you have a lengthy dev/beta/prod rollout process to a very large number of machines, this can bite you. Just this week, Chile and Turkey are making changes, so prepare to update :)

rlmw 13y ago
The distribution of new Java versions is already decoupled from tzdata updates. If you want to update your tzdata then you should use the tzupdater tool that is shipped with Java. This has been updated to support JSR-310. If you want to perform the updates then this is just a commandline tool and can be integrated into chef/puppet etc. as needed. There was discussion during the development of JSR-310 about the inclusion of Java library methods to update a running JVM. There are a load of "not obvious to a developer" things that happen if you do this and it was decided the technical complexity and potential confusion outweighed the benefit of implementing it.
- apaprocki 13y ago
  That's what I was referring to, though, as being operationally expensive. I need to ensure we're using up-to-date tzdata, but there could be multiple different runtimes running on hosts in locations I'm not aware of. All I really wanted to say is that I want to be able to do a file drop of all of the binary data in a well-known location on all hosts and have all of the relevant languages / runtimes point to those files without running any additional tools, etc. Complexity starts multiplying once you add these external processes because of additional failure modes -- e.g., someone can run the tool manually and make things out of sync, no tools to monitor that things do stay in sync, handling backout of bad deployed data, installing a new not-yet-updated JRE version to a machine.

rlmw 13y ago

The distribution of new Java versions is already decoupled from tzdata updates. If you want to update your tzdata then you should use the tzupdater tool that is shipped with Java. This has been updated to support JSR-310. If you want to perform the updates then this is just a commandline tool and can be integrated into chef/puppet etc. as needed. There was discussion during the development of JSR-310 about the inclusion of Java library methods to update a running JVM. There are a load of "not obvious to a developer" things that happen if you do this and it was decided the technical complexity and potential confusion outweighed the benefit of implementing it.

apaprocki 13y ago
That's what I was referring to, though, as being operationally expensive. I need to ensure we're using up-to-date tzdata, but there could be multiple different runtimes running on hosts in locations I'm not aware of. All I really wanted to say is that I want to be able to do a file drop of all of the binary data in a well-known location on all hosts and have all of the relevant languages / runtimes point to those files without running any additional tools, etc. Complexity starts multiplying once you add these external processes because of additional failure modes -- e.g., someone can run the tool manually and make things out of sync, no tools to monitor that things do stay in sync, handling backout of bad deployed data, installing a new not-yet-updated JRE version to a machine.