Time zones in Java: design discussion
Background: Olson time zone database
This database maintains the time zone information including the periods when Daylight Savings Time (DST) is in effect, for all locations around the world.
For its description and history, see the Wikipedia article.
What is important for us, is that this database is quite dynamic, with changes being introduced every few months if not weeks, as local authorities all over the world change the dates of their daylight savings time from year to year.
For example, in the United States, some counties have their own rules for Daylight Savings Time, and this contribute to the number of entries in this database. In fact, it currently has 408 entries according to the special Wikipedia article dedicated to this list; bear in mind that the contents of each entry – the dates its DST is in effect – may change from time to time.
In my country, Israel, the issue of Daylight Savings Time is highly political and is decided by parliament debate; for some parties changes in Daylight Savings Time are part of their political program and they write these changes in coalition agreements; see more details here.
A brief survey of Java time zone design
The design of Java time zone functionality is as follows.
Java maintains its own time zone database, see Oracle documentation. This database is maintained to match the Olson time zone database through updates to JRE that are regularly issued.
In addition, Java allows custom time zones of the form GMT+<offset> (e.g., GMT+3) which do not bear any daylight savings time information.
Whenever Java needs to find out the current time and time zone, it turns to the operating system and tries to identify the time zone which is currently set on the computer, with a time zone in its database.
On the first glance: why this design seems to be wrong
When I first bumped into the Java incorrect time zone bug on Windows, I thought that there was a problem with the Java design, as follows.
Java Runtime (JRE) maintains its own time zone database and the operating system (OS) maintains its own database.
Both databases are periodically updated against the standard Olson database but these updates are not synchronized.
Thus, whenever Olson database is changed, there is some period when one of the two databases, JRE and OS, is already updated, while the other one is not. During this period, the two databases mismatch.
In many cases user needs his program to correctly understand the time changes according to his operating system, not according to some abstract database maintained by Java. In such cases user needs access to the OS database rather than the one maintained by Java.
However, Java does not give such an option.
Rather, it despises it completely: all it does, it tries to ascertain the name of the current time zone from the OS data, and use its own database. When it fails, user gets a completely different time zone.
According to this line of reasoning, in addition to the time zones in the database maintained by Java, user should be able to use the time zones in the OS time zone database, or at least, the current time zone of the operating system, together with its DST information.
To summarize, the problems with the Java time zone design are as follows:
- Java does not give access to time zones maintained by the operating system.
- There is a possibility of mismatch between the time zone databases maintained by Java and by the operating system, and it is not clear how applications can deal with it.
On the second glance: why the current Java design is correct
We address the above problems one by one.
Time zones maintained by Windows: better not give access to them
The information on the current time zone on Windows may be unreliable, both the current time zone offset and the dates when DST is in the effect; see our discussion here. If we let user use this information, it may turn out to be corrupt.
This means that we cannot rely on the current time zone information provided by the OS, and need to allow for the possibility that this information is incorrect or corrupt.
Here we suggest that in such case the best solution is to allow user to indicate manually the correct time zone in the Java database.
With that, there is no point in taking trouble to extract the DST information from the operating system.
In other words, there is no point in taking trouble to give access to the time zones maintained by the OS since (1) we cannot always determine the current one correctly and (2) the DST information may be corrupt.
Thus, it is better to use our own database and use the operating system only to identify the current time zone in our database. This is the decision taken by Java.
The mismatch is not a problem
Our concern is with the mismatch between the two time zone databases, the one maintained by Java and the one maintained by the operating system; a Java application needs to be able to deal with it.
Any developer that needs to deal with future events in different time zones, needs to take into account the following two possibilities:
- The Daylight Savings Time information may change, and this change may happen before the event in question takes place.
- Thus, if we determine now that a future event takes place during DST, we need to prepare for the possibility that the DST rules may change in the meantime and the event will take place during the Standard time rather than DST.
- In addition, the local time zone database (whether JRE, or OS, or both) may fail to be updated correctly by the event time.
- In such case, the computer or a Java application/applet will show the local time incorrectly, and the user will have to change the time zone manually to fix the local time set in the application or on the computer.
The possibility of the mismatch between the DST information in the JRE time zone and in the OS time zone seems to be trivial in comparison with the these two possibilities; if they are taken care of, the mismatch between the databases seems to be easy to deal with.
©Baruch Youssin 2014
Read also: