Allow alternate location for time zone data files about joda-time

[brandonheck]

I'd be in favor of this as a good interim solution to #17.

[jodastephen]

One problem is that time-zone data isn't one file, but lots of files in Joda-Time. I suspect that you are thinking about having a central network location for the files, so multiple applications can share the same data. Not something I overly like the sound of.

This is also possible to write today outside of Joda-Time, as the time-zone provider interface is public and should provide all the control you need.

[johnjaylward]

it doesn't have to be a network location. I'd be OK with updating each machine separately since I'd have to configure each app to point at a location anyway. A simple script to download the archive and unzip it on a schedule would be easy enough to set up on machines that need it, and to ignore on machines that don't.

I don't see why the system property would have to care what kind of location it is (network or local) as long as it's configurable

[brandonheck]

The problem that I see with your suggestion, @jodastephen, is that it would require any application that uses joda-time that is interested in subscribing to this type of update mechanism to not only bundle a library that calls into the time-zone provider interface, but also to know that the library exists. With the behavior suggested by @derekdobler, any application that uses joda-time has the ability to subscribe to this type of update mechanism, but if they don't want it, they don't have to use it. In a large enterprise deployment scenario, having the ability to activate this across hundreds of applications is essential. I am not sure I understand your hesitation to share timezone data across multiple applications. Could you elaborate as to why you would find this behavior undesirable?

[jodastephen]

I don't have a big problem with this idea, although I am concerned that it adds extra complexity. This is particularly interesting in terms of how to compile the TZDB files, and the fact that they consist of lots of separate compiled binary files in a zip. So any change would require tricky maven changes to be able to build a time-zone only zip/jar, extra documentation plus source code changes.

Really, its closer to providing a separate maven artifact containing just the time-zone data. A classpath search would find all installed time-zone data on the classpath and use the TZDB version string (2013c) to determine the latest to use.

[brandonheck]

@jodastephen I think the workflow here would be for consumers to use the ZoneInfoCompiler to generate the new binaries that Joda-Time needs and set the property for where Joda-Time should load those resources (rather than the default location of src/main/java/org/joda/time/tz/src). This would provide a way for Joda-Time to be able to consistently pick up the location of the new files, although it would require the JVM in which Joda-Time is running to cycle. Unfortunately we haven't been able to find a way that consistently allows for the new files to be on the classpath before what is bundled in with Joda-Time.

I think I understand the way you are thinking of this; more of a holistic solution of providing new time zone information for consumers of Joda-Time without making them take an entirely new version of Joda-Time. If you want to do that, I think i would be entirely possible, but it would take more effort than what I think @derekdobler is suggesting. His suggestion, as I understand it, would leave the burden of providing the updated binaries read by Joda-Time up to the consumers only if they desired that functionality. Otherwise, the time zone information update mechanism for Joda-Time would continue as it currently exists.

[derekdobler]

That's correct, the ZoneInfoCompiler is scriptable and can be used to generate updated TZDB files. We're wanting to allow joda-time to cycle the JVM and pick up any updated information from a location specified by an optional JVM argument. This would allow all future versions of joda-time to have the same versions of rules if desired and not have to worry about rebuilding to get current TZDB information.

[jodastephen]

See also this thread.

[alex-stark]

@jodastephen I don't believe that covers the use case @derekdobler is looking for either. That looks like an easy way to update time zone data at build time. However, he is looking for a way to update time zone data without requiring a new build. A way to update the data after the app has been deployed. Something like this:

• set system property to point to a directory
• generate TZDB files and place in specified directory
• cycle JVMs that use joda-time
• at startup joda-time reads system property and loads tz data from there instead of src/main/java/org/joda/time/tz/src
• if system property isn't set I'd assume default behavior would be desired.

[derekdobler]

I'd be willing to submit a pull request with the changes and scripts to compile the TZData against a Windows/Unix environment if you're interested in the idea. While the thread that was linked is an interesting idea, it would still require a rebuild in order to pick up the changes. @alex-stark has the correct workflow for what we're trying to accomplish, some script to pick up the latest published version of the TZData and then a cycle to allow all applications using joda-time to get the updated rule sets (if a system property was set to point to this directory.)

[jodastephen]

I would point out that Joda-Time doesn't use src/main/java/org/joda/time/tz/src, it uses org/joda/time/tz in the classpath. The proposed change will allow a second jar file on the classpath to be used.

[derekdobler]

The problem we face is we don't have a good way to modify the classpath for every application that uses joda-time outside of reassembling, namely RCP applications. Would the proposed artifact idea be able to pick up all of the classpath information when run inside of a J2EE environment? One of our needs lies in Websphere applications where parent-last classloading applications breaks the current method of overriding the classpath when placing the updated TZData files inside of a shared library.

[johnjaylward]

@derekdobler I believe the proposed solution of having tzdata be a separate jar solves that issue as long as you aren't running from a compressed WAR. if you run from an exploded WAR, then you can just overwrite the old tzdata jar with the new one, and restart websphere (although I don't use websphere, so maybe I'm wrong on how "easy" this would be for it)

[johnjaylward]

My one concern with the dual jar solution is that it would require the tzdata APIs to remain binary compatible with older joda jars.

My original proposal for the system property was not to indicate a location of the compiled tz data, but the raw tzdata, and Joda would compile it fresh before running. This way as long as the tzdata format stayed the same format, Joda itself wouldn't have to be updated at all and there shouldn't be API compatibility issues.

[derekdobler]

@johnjaylward the Websphere portion I believe could be done with the duel jar solution but we still run into the issue with RCP applications getting the updated artifact on the classpath without reassembly. Our clients don't have a common directory structure where we can easily go and swap out the artifacts from a scriptable perspective. Spanning hundreds of clients with many containing applications using joda-time, the only way we could go about giving the updated TZData with our workflows would be to repackage our RCP solutions which is less ideal than just setting a property to pick up updated data.

[alex-stark]

@johnjaylward and @jodastephen I think we are still not exactly on the same page. Splitting out the tz data into a separate jar is a good first step. However, as you say it still requires we place that new jar on the classpath. However, for several of our deployed assemblies we don't have access to modify the classpath nor do we know what directories are on the classpath. In our case the ability to specify a common shared directory to house the tz data that could be utilized by all joda consumers would be by far the cleanest way to deploy without requiring all of our assemblies to reassemble (which can numbers in the 100s.)

[alex-stark]

Just wanted to circle back and get this wrapped up. Are there any outstanding questions about what we're looking for? If we submitted a pull request would it have any chance?

[jodastephen]

Ultimately, I don't want to special case one particular approach of compiling and loading files dynamically. Its not something I'm convinced is right for the core.

The mechanism for achieving this already exists. Write an implementation of org.joda.time.tz.Provider and plug it in using the system property org.joda.time.DateTimeZone.Provider.

Since I also don't really want to be resonsible for future maintanance, I'd rather it was hosted as a separate GitHub project. I'm happy to link to it from the "related projects" page, and a pull request is welcome for that.

If it turns out to be super-popular, then perhaps it could be brought into the core.

[alex-stark]

That seems fair. We did a bit more playing around with the creating our own Provider yesterday and so far it looks like we can get what we need using that pattern. So at the moment we're just planning on using that option.

Thanks!

[jodastephen]

If you do that, I'd love to see it published on GitHub, so others can benefit ;-)

[johnjaylward]

I'd love to see that too. I wish I could get enough free time to help you out with it as it seems to be what I'm looking for as well.

[kaiyuan01]

Sorry to revive an old thread. So far I did not see a viable solution/implementation or did I miss anything?

Another alternative - if all we need is to ask DateTimeZone to look into another file folder to get compiled data, can we add an additional system property such as "org.joda.time.DateTimeZone.Data" and change Line 488:

provider = new ZoneInfoProvider("org/joda/time/tz/data");
instead of hard code it as "org/joda/time/tz/data", change it so that

1. if that system property is null: provider = new ZoneInfoProvider("org/joda/time/tz/data");
2. otherwise:
   String dir = System.getProperty("org.joda.time.DateTimeZone.Data");

provider = new ZoneInfoProvider(new File(dir)); // Note if you pass a string, it expects in in class path!

Will this be a simpler solution without any code change on all client codes?

BTW, I am willing to get that done, how can I get that code to be included in the next snapshot/release? What is the process to get contribution checked in?

Thanks.

[derekdobler]

@jeffdeng88 So update on our part of the issue. We ended up creating a provider implementation that would be used to locate external time zone files through the environment variable but after creating it, the project scope changed and we decided not to go forward with it. Going back to the initial suggestion in this thread, instead of creating a version of joda-time that takes in a new system property "org.joda.time.DateTimeZone.Data", creating a provider implementation on the classpath would not only allow the consumer to find and load external files, it would also allow that provider implementation to be used in previous versions of joda-time as well.

While we liked the idea of loading the external files at the start, we found over the course of development there were too many risks associated with trying this approach in large enterprise deployment environments.

[jodastephen]

I'm always happy to look at a GitHub pull request, but I don't make promises to include them :-)

[kaiyuan01]

Thanks for all the help.
I am trying to use my custom implemented ZoneInfoProvider but it did not seem to work. There is no logs(this is sth we have to add a bit), no printouts so I don't know what's wrong. (ours is a soap web services so the lib is inside a war file).

So I tried explicitly to set the default provider: -Dorg.joda.time.DateTimeZone.Provider=org.joda.time.tz.ZoneInfoProvider, and surprizingly got tyhe following error:

Exception in thread "main" java.lang.InstantiationException: org.joda.time.tz.ZoneInfoProvider
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at org.joda.time.DateTimeZone.getDefaultProvider(DateTimeZone.java:427)
at org.joda.time.DateTimeZone.setProvider0(DateTimeZone.java:393)
at org.joda.time.DateTimeZone.(DateTimeZone.java:114)
at org.joda.time.chrono.GregorianChronology.(GregorianChronology.java:71)
at org.joda.time.chrono.ISOChronology.(ISOChronology.java:66)
at org.joda.time.base.BaseDateTime.(BaseDateTime.java:61)
at org.joda.time.DateTime.(DateTime.java:84)
at ....testFromErdsTimeZone2TimeZoneInformation(JodaDateTimeZoneTest.java:83)
at ...JodaDateTimeZoneTest.main(JodaDateTimeZoneTest.java:71)
System property org.joda.time.DateTimeZone.Provider is: org.joda.time.tz.ZoneInfoProvider

Is it because we are invoking newInstance() while we don't have a constructor with 0 params?

I am wondering if you successfully made custom ZoneInfoProvider, did you (have to) write a constructor with 0 params? As shown above, the default provider, if specified explicitly via command line (sytem property), it will fail.

Thanks for any pointers in advance.

Jeff

[kaiyuan01]

Just an update: a default constructor with 0 arguments is necessary for a custom provider.

[jodastephen]

Added system property "org.joda.time.DateTimeZone.Folder". If specified, the tz data will be loaded from that folder instead of the classpath. Part of investigating #220.