Requirements for tzdb.jar

[jodastephen]

The tzdb included in the JDK needs to be easily replaced/supplemented. must vs nice to have list:

1. For a standard JDK downloaded by a "normal" user, the JSR-310 tzdb must be the same raw data as that used by java.util.TimeZone.
2. The TZUpdater tool, or a similar mechanism, must be available for a "normal" user to update the data in a standard JDK. It must replace both the data for ZoneId and TimeZone.
3. It would be nice to have the java.util.TimeZone class depend on ZoneId internally to eliminate two sets of data in the JDK. This may require additional public methods on ZoneId.
4. It must be possible for a user to elect to replace the tzdb data for ZoneId classes with a set of data that includes the full historical set of tzdb data. If (3) is implemented, then this will also affect TimeZone. Note that this requirement effectively allows a user to update the time-zone data without using the TZUpdater tool (or equivalent).
5. The tzdb with history file must be capable of publishing the same IDs as the original JDK data. The provider mechanism does not permit this as currently written, thus the full history tzdb can be perceived as a replacement for the original.
6. The mechanism to register/include the history tzdb file is open to design choices. Options include (a) specifying the default provider in configuration, (b) specifying the tzdb jar file location (c) adding tzdb.jar file to the endorsed location.
7. The mechanism to create the alternate tzdb file with history is open to design choices. Options include specifying the file format, and making the TZDB compiler class public. Given a choice, I think I would prefer a public class to a public file format. If the default provider is made pluggable, then no explicit mechanism would be required to create the file, as users would instead write their own provider and their own file format.
8. It must be possible to replace the default tzdb data for ZoneId, if not TimeZone, with a provider that loads and updates the data over the network dynamically. While we may disagree on the benefits of this approach, we must not prevent it. Again, I would note that being able to replace the default provider would meet this requirement, but is not the only option.
9. It is a desirable, nice to have, that any alternate tzdb such as the "full history tzdb" can be made available as a jar file on maven central and integrated on the normal classpath (rather than the bootclasspath).
10. In the event of no tzdb being available, the system must be able to start and run using only ZoneOffset IDs.

See also #197 on leap seconds, which are held in the same file.

[xuemingshen]

With the following changes we currently put in -j.u.TimeZone now shares the tzdb.jar -java.time.zone.DefaultZoneRulesProvider system provider for default zrules provider It appears most of the issues mentioned above have been solved. The only things left seem to be

(1) whether or not the j.u.TimeZone should also use the zone data if the default provider is something other than the default. This might be something "nice to have". But I don't think it's a must, and probably it's not going to happen in jdk8 timeframe.

(2) how to support #7. I don't think "specifying the file format" and/or "make tzdb compiler public" are the best and desired choice. The ZoneRulesProvider class is designed exactly for this purpose (with the newly added DefaultZoneRulesProvider system property). Any "customized" zone rules support could/should just go via this SPI interface, Implement your customized "provider" and then specified it as the default zonerules provider.

10 should not be an issue and a requirement. A complete JDK/JRE installation should always have the tzdb data available.

[jodastephen]

I agree that we have most of this now. Here are the problems:

It seems that ZoneInfoFile does not respect the default provider system property. That makes it more likely that the TimeZone implementation will be out of line with ZoneId creating confusion. Could ZoneInfoFile use ZoneRulesProvider internally, so data is only loaded once from the file?

Point 7 (data format) is not a problem if the default provider mechanism works fully.

The system property approach is quite difficult to use in some setups. The cases are:

• user doesn't care and just gets the JDK default TZDB
• user wants to upgrade to a later version of rules
• user wants to take total control

The first case is easy. The second case is more interesting. Ideally, they should just have to download a jar from Oracle or Maven and add it to their classpath (possibly bootclasspath). Has the mechanism for this been agreed yet (currently its the tzupdater tool).

For the third case, I think users can manage to set a system property. But really, they want their changes to affect both ZoneId and TimeZone, which isn't the case right now.

[jodastephen]

The code uses the property java.time.zone.DefaultZoneRulesProvider with the ClassLoader.getSystemClassLoader(). If I understand correctly, this means that applications cannot just include their own provider in the regular application classpath. Does it need to be the system class loader?

[xuemingshen]

The "system class loader" is the application class loader, it will/should lookup the targeted class from boot-cp, ext-cp and then the app-cp.

[jodastephen]

Good that the applciation class loader can be used.

The most practical way to get up to date TimeZone might be for ZoneRulesProvider to be able to provide instances of TimeZone. The default implementation would use ZoneInfoFile. It would more closely link the old code with the new code.

Closing as we're not doing this now.