This database maintains the time zone information including the \t\tperiods when Daylight Savings Time (DST) is in effect, for all \t\tlocations around the world.<\/p>\n
\t\tFor its description and history, see the Wikipedia \t\t\tarticle<\/a>. \t<\/p>\n What is important for us, is that this database is quite \t\tdynamic, with changes being introduced every few months if not weeks, \t\tas local authorities all over the world change the dates of their \t\tdaylight savings time from year to year.<\/p>\n \t\tFor example, in the United States, some counties<\/em> have their \t\town rules for Daylight Savings Time, and this contribute to the number \t\tof entries in this database. In fact, it currently has 408 entries \t\taccording to the special \t\t\tWikipedia article dedicated to this list<\/a>; bear in mind that the \t\tcontents of each entry \u2013 the dates its DST is in effect \u2013 may change \t\tfrom time to time. \t<\/p>\n \t\tIn my country, Israel, the issue of Daylight Savings Time is highly \t\tpolitical and is decided by parliament debate; for some parties \t\tchanges in Daylight Savings Time are part of their political program \t\tand they write these changes in coalition agreements; see more details \t\t \t\t\there<\/a>. \t<\/p>\n The design of Java time zone functionality is as follows.<\/p>\n \t\tJava maintains its own time zone database, see \t\t\tOracle documentation<\/a>. This database is maintained to match the Olson \t\ttime zone database through updates to JRE that are regularly issued. \t<\/p>\n In addition, Java allows custom time zones of the form \t\tGMT+<offset> (e.g., GMT+3) which do not bear any daylight \t\tsavings time information.<\/p>\n Whenever Java needs to find out the current time and time zone, \t\tit turns to the operating system and tries to identify the time zone \t\twhich is currently set on the computer, with a time zone in its \t\tdatabase.<\/p>\n \t\tWhen I first bumped into the Java incorrect \t\t\ttime zone bug on Windows<\/a>, I thought that there was a problem with the \t\tJava design, as follows. \t<\/p>\n Java Runtime (JRE) maintains its own time zone database and the \t\toperating system (OS) maintains its own database.<\/p>\n Both databases are periodically updated against the standard \t\tOlson database but these updates are not synchronized.<\/p>\n Thus, whenever Olson database is changed, there is some period \t\twhen one of the two databases, JRE and OS, is already updated, while \t\tthe other one is not. During this period, the two databases mismatch.<\/p>\n In many cases user needs his program to correctly understand the \t\ttime changes according to his operating system, not according to some \t\tabstract database maintained by Java. In such cases user needs access \t\tto the OS database rather than the one maintained by Java.<\/p>\n However, Java does not give such an option.<\/p>\n Rather, it despises it completely: all it does, it tries to \t\tascertain the name of the current time zone from the OS data, and use \t\tits own database. When it fails, user gets a completely different time \t\tzone.<\/p>\n According to this line of reasoning, in addition to the time \t\tzones in the database maintained by Java, user should be able to use \t\tthe time zones in the OS time zone database, or at least, the current \t\ttime zone of the operating system, together with its DST information.<\/p>\n To summarize, the problems with the Java time zone design are as \t\tfollows:<\/p>\n We address the above problems one by one.<\/p>\n \t\tThe information on the current time zone on Windows may be unreliable, \t\tboth the current time zone offset and the dates when DST is in the \t\teffect; see our discussion \t\t\there<\/a>. If we let user use this information, it may turn out to be \t\tcorrupt. \t<\/p>\n This means that we cannot rely on the current time zone \t\tinformation provided by the OS, and need to allow for the possibility \t\tthat this information is incorrect or corrupt.<\/p>\nA brief survey of Java time zone design<\/span><\/h2>\n
On the first glance: why this design seems to be wrong<\/span><\/h2>\n
\n
On the second glance: why the current Java design is correct<\/span><\/h2>\n
Time zones maintained by Windows: better not give access to \t\tthem<\/span><\/h3>\n