2007 US Daylight Savings change time zone support in JDK 1.3

Sun has supported the 2007 US Daylight Savings change in recent versions of its JDKs 1.4 and 1.5. It has made partial Daylight Savings changes to JDK 1.3, but it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone.

Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3.

If any Sun Java staff can explain the reasons for being unable to implement the change in 1.3 (or at least some kind of workaround that an individual JVM user could enable), please fill me in. Any pointers on cleanly setting up a custom workaround would be valuable too.

If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround?

More details....

What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application.

JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates.

JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly.

If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds:

1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible.

2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones.

Prior related Java Forum topics:

* http://forum.java.sun.com/thread.jspa?forumID=31&threadID=645874 (Java Essentials - Java Programming) winds up referencing the JDK 1.4 patch as a solution, and there is some discussion about how future/historic dates affect applications

* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=735038 (Deploying - Java Upgrade) just talks about 1.4 and 1.5 patches

* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=717268 (Deploying - Java Upgrade) also just talks about 1.4 and 1.5 patches

* http://forum.java.sun.com/thread.jspa?forumID=37&threadID=703214 (Specifications - Java Virtual Machine (JVM)) also just talks about 1.4 and 1.5

Related Sun Java Bug Database bugs:

* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1.

* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1.

* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates.

Other articles:

* Sun Java article http://java.sun.com/developer/technicalArticles/Intl/USDST/ refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5

* Server Side article http://www.theserverside.com/news/thread.tss?thread_id=42212 refers to fixes in 1.4 and 1.5 for the DST issue, and the discussion about 1.3 doesn't lead anywhere

Thanks for any info or advice available,

Jim

[4526 byte] By [jameskevindoyle1a] at [2007-10-3 11:04:26]
# 1
Jim, Nice write up. Hope we find some help.
rmalouina at 2007-7-15 13:26:53 > top of Java-index,Desktop,Deploying...
# 2

Jim,

Thanks so much for documenting your findings. Almost gave up on 1.3 if it were because of your post.

However, I have something to add to your finding:

While JDK 1.3.1_19 works in either 2006 or 2007 but not both without restart, it doesn't work at all under Windows 2000.

Bizarre, it works on Windows XP but not Windows 2000!!!

If anyone has any workaround, please post. TIA!

David

hou2a at 2007-7-15 13:26:53 > top of Java-index,Desktop,Deploying...
# 3

David,

The 1.3.1_19 time zone rules should be entirely inside platform-neutral java code (see src.jar's TimeZone.java) so if Windows 2000 vs. XP is an issue, I'm thinking maybe the time zone ID it's pulling from the environment is different. Try printing out the "user.timezone" system property on Windows 2000 vs. XP and seeing if it's different. Maybe on your Windows 2000 machine, the time zone is just "GMT-05:00" or another generic GMT-offset time zone ID, in which case it won't know about DST at all. Our machines are "America/New_York" which identifies specific DST rules inside TimeZone.java.

We haven't gotten any feedback from Sun on improving the support in JDK 1.3, so we're going ahead with a workaround for now.

I'm not sure about our company's current policies on posting code, so I'll just explain what we're doing:

- We copied SimpleTimeZone.java from the JDK into our own package so that we could call its package-private methods (getOffset with 8 args). We had to change its inDaylightTime() method because of other package methods it uses.

- We implemented a class called HistoricalTimeZone, extending TimeZone.

- HistoricalTimeZone contains an int rawOffset field giving it the general time zone offset (5 hours in our case)

- HistoricalTimeZone contains a collection of SimpleTimeZones. Since SimpleTimeZone correctly implements DST offset checks for a given year, you can just use one SimpleTimeZone for each different set of DST rules. The collection is a TreeMap mapping from year numbers to SimpleTimeZone instances.

- Constructor is like SimpleTimeZone constructor and sets the ID, rawOffset, and creates a default (year-0) SimpleTimeZone to add to the collection.

- Has addRule method with a year argument, and arguments like those in the SimpleTimeZone constructor, so it can create a new SImpleTimeZone and add it to the collection.

- Implements inDaylightTime similar to SimpleTimeZone - creates new GregorianCalendar, sets its time, and gets the DST_OFFSET.

- Implements useDaylightTime by looping over its SimpleTimeZones

- Implements getOffset with 6 args (the public API) the same way SImpleTimeZone does - it just calls getOffset with 8 args.

- The key method is getOffset with 8 args, which looks up the correct SimpleTimeZone for the year - "offsetRules.get(offsetRules.headMap(new Integer(year + 1)).lastKey())" - and delegates to the SimpleTimeZone's getOffset method.

- The TimeZone we pass to all of our application code, Calendars, and SimpleDateFormats, is a HistoricalTimeZone constructed with the two sets of US Eastern rules, using exactly the same data values as the SimpleTimeZones constructed inside JDK's TimeZone.java.

jameskevindoyle1a at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 4

Is there any way to verify that timezone data was updated? The output doesn't give me a warm feeling.

cd /database/aux/patch/tzupdater2006p

/database/ias_infra10.1.2/jdk/jre/bin/java -jar tzupdater.jar --update

--verbose

java.home: /database/u01/app/oracle/product/ias_infra10.1.2/jdk/jre

java.vendor: Sun Microsystems Inc.

java.version: 1.4.2_06

JRE time zone data version: tzdata2006p

Embedded time zone data version: tzdata2006p

You have the same version as the embedded one.

In the readme it says: --test

Runs verification tests only and exit. If the JRE has time zone data that

doesn't match the one in the tool, the verification tests report errors and

fail.

When I run it one a java executable I didn't try to patch yet it gives no

error. Oracle Support said I need to run this to make the JDK in their 10.1.2 Application Server be compliant. It seems like the tools is telling me I don't need to run it?

/database/ias_infra10.1.2/jdk/bin/java -jar tzupdater.jar --test --verbose

java.home: /database/u01/app/oracle/product/ias_infra10.1.2/jdk/jre

java.vendor: Sun Microsystems Inc.

java.version: 1.4.2_06

JRE time zone data version: tzdata2006p

Embedded time zone data version: tzdata2006p

Validating the time zone data

Validation complete

/database/ias_infra10.1.2/jdk/jre/bin/java -jar tzupdater.jar tzupdater.jar

--version <

tzupdater version 1.0.0-b03

JRE time zone data version: tzdata2006p

Embedded time zone data version: tzdata2006p

Doesn't it appear that the timezone data in Application Server 10.1.2.0.2 is

the same as the compliant one?

KBarneya at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 5

Hi KBarney

I think u have the correct data file. to make sure see the "zi" dir is backed up in ur java lib folder or not.

if u have suspicion than run the tzupdater tool again.

this tool must be run for each jre/java version on your machine separately.

I tried this on 1.4.2.13 and not on 1.5.0.10. here is the result:

C:\Program Files\Java\j2re1.4.2_13\bin>java -jar c:\tzupdater\tzupdater2006p\tzu

pdater.jar -t -v

java.home: C:\Program Files\Java\j2re1.4.2_13

java.vendor: Sun Microsystems Inc.

java.version: 1.4.2_13

JRE time zone data version: tzdata2006p

Embedded time zone data version: tzdata2006p

Validating the time zone data

Validation complete

--

C:\tzupdater\tzupdater2006p>java -jar tzupdater.jar --test --verbose

java.home: C:\Program Files\Java\jre1.5.0_10

java.vendor: Sun Microsystems Inc.

java.version: 1.5.0_10

JRE time zone data version: tzdata2006k

Embedded time zone data version: tzdata2006p

Validating the time zone data

/data/tzdata2006p.test:990: test failed: America/Managua

/data/tzdata2006p.test:1465: test failed: America/Havana

/data/tzdata2006p.test:1466: test failed: America/Havana

/data/tzdata2006p.test:1847: test failed: Cuba

/data/tzdata2006p.test:1848: test failed: Cuba

/data/tzdata2006p.test:2024: test failed: America/Campo_Grande

/data/tzdata2006p.test:2026: test failed: America/Campo_Grande

/data/tzdata2006p.test:2028: test failed: America/Campo_Grande

/data/tzdata2006p.test:2030: test failed: America/Campo_Grande

/data/tzdata2006p.test:2032: test failed: America/Campo_Grande

/data/tzdata2006p.test:2034: test failed: America/Campo_Grande

/data/tzdata2006p.test:2036: test failed: America/Campo_Grande

/data/tzdata2006p.test:2038: test failed: America/Campo_Grande

/data/tzdata2006p.test:2040: test failed: America/Campo_Grande

/data/tzdata2006p.test:2046: test failed: America/Cuiaba

/data/tzdata2006p.test:2048: test failed: America/Cuiaba

/data/tzdata2006p.test:2050: test failed: America/Cuiaba

/data/tzdata2006p.test:2052: test failed: America/Cuiaba

/data/tzdata2006p.test:2054: test failed: America/Cuiaba

/data/tzdata2006p.test:2056: test failed: America/Cuiaba

/data/tzdata2006p.test:2058: test failed: America/Cuiaba

/data/tzdata2006p.test:2060: test failed: America/Cuiaba

/data/tzdata2006p.test:2062: test failed: America/Cuiaba

/data/tzdata2006p.test:2471: test failed: America/Montevideo

/data/tzdata2006p.test:2472: test failed: America/Montevideo

/data/tzdata2006p.test:2475: test failed: America/Montevideo

/data/tzdata2006p.test:2476: test failed: America/Montevideo

/data/tzdata2006p.test:2479: test failed: America/Montevideo

/data/tzdata2006p.test:2480: test failed: America/Montevideo

/data/tzdata2006p.test:2483: test failed: America/Montevideo

/data/tzdata2006p.test:2484: test failed: America/Montevideo

/data/tzdata2006p.test:2487: test failed: America/Montevideo

/data/tzdata2006p.test:2494: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2496: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2498: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2500: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2502: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2504: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2506: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2508: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2510: test failed: America/Sao_Paulo

/data/tzdata2006p.test:2516: test failed: BET

/data/tzdata2006p.test:2518: test failed: BET

/data/tzdata2006p.test:2520: test failed: BET

/data/tzdata2006p.test:2522: test failed: BET

/data/tzdata2006p.test:2524: test failed: BET

/data/tzdata2006p.test:2526: test failed: BET

/data/tzdata2006p.test:2528: test failed: BET

/data/tzdata2006p.test:2530: test failed: BET

/data/tzdata2006p.test:2532: test failed: BET

/data/tzdata2006p.test:2537: test failed: Brazil/East

/data/tzdata2006p.test:2539: test failed: Brazil/East

/data/tzdata2006p.test:2541: test failed: Brazil/East

/data/tzdata2006p.test:2543: test failed: Brazil/East

/data/tzdata2006p.test:2545: test failed: Brazil/East

/data/tzdata2006p.test:2547: test failed: Brazil/East

/data/tzdata2006p.test:2549: test failed: Brazil/East

/data/tzdata2006p.test:2551: test failed: Brazil/East

/data/tzdata2006p.test:2553: test failed: Brazil/East

/data/tzdata2006p.test:3451: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3452: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3453: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3454: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3455: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3456: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3457: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3458: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3459: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3460: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3461: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3462: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3463: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3464: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3465: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3466: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3467: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3468: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3469: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3470: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3471: time zone not found: Europe/Podgorica

/data/tzdata2006p.test:3791: test failed: ART

/data/tzdata2006p.test:3814: test failed: Africa/Cairo

/data/tzdata2006p.test:3844: test failed: Asia/Amman

/data/tzdata2006p.test:3848: test failed: Asia/Amman

/data/tzdata2006p.test:3852: test failed: Asia/Amman

/data/tzdata2006p.test:3856: test failed: Asia/Amman

/data/tzdata2006p.test:3860: test failed: Asia/Amman

/data/tzdata2006p.test:3887: test failed: Asia/Damascus

/data/tzdata2006p.test:3908: test failed: Asia/Gaza

/data/tzdata2006p.test:3911: test failed: Asia/Gaza

/data/tzdata2006p.test:3915: test failed: Asia/Gaza

/data/tzdata2006p.test:3919: test failed: Asia/Gaza

/data/tzdata2006p.test:3923: test failed: Asia/Gaza

/data/tzdata2006p.test:4035: test failed: Egypt

/data/tzdata2006p.test:4901: test failed: Australia/Perth

/data/tzdata2006p.test:4902: test failed: Australia/Perth

/data/tzdata2006p.test:4905: test failed: Australia/Perth

/data/tzdata2006p.test:4906: test failed: Australia/Perth

/data/tzdata2006p.test:4909: test failed: Australia/Perth

/data/tzdata2006p.test:4910: test failed: Australia/Perth

/data/tzdata2006p.test:4914: test failed: Australia/West

/data/tzdata2006p.test:4915: test failed: Australia/West

/data/tzdata2006p.test:4918: test failed: Australia/West

/data/tzdata2006p.test:4919: test failed: Australia/West

/data/tzdata2006p.test:4922: test failed: Australia/West

/data/tzdata2006p.test:4923: test failed: Australia/West

Validation tests failed.

-Ranjan

pranjanka at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 6
Where did you get Java 1.4.2_13 from?It does not seem to be on the Sun web-site anywhere, though it is mentioned in the TZ updater README...
sebbaza at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 7
1.4.2.13 is here http://java.sun.com/j2se/1.4.2/download.html
darkdreamweavera at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 8

Hi

i have a problem with jdk 1.4.2-13. i was using jdk 1.4.2-04 in UNIX system.

i was able to produce report on pdf file of "Arial" font using style pro in java.

when i migrated it to jdk 1.4.2-13 version i found my report getting generated in different font.

what is the solution... how to solve it....

digia at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 9
Have problem with timestamp with timezone field around March 11 midnight to march 11 3AM . Using JDK 1.4.2_13 and database is oracle Any solution?ThanksKavi
abcana at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...
# 10

If your using an earlier release of JDK 1.3.1and can't update to JDK 1.3.1_20 then in order to update the time zone data simply copy the class java.util.TimeZoneData from rt.jar on 1.3.1_20 and replace the one in the older version. Time zone information is hard coded here up to a certain version.

limnestora at 2007-7-15 13:26:54 > top of Java-index,Desktop,Deploying...