Timezone Issues

[Scott Selikoff]

I noticed the computer on a OpenSuse 10.3 computer was off by an hour in java programs, but correct in the system settings. I did some digging and discovered some oddities.

First off, assume the time in the system properties (and computer BIOS) is set correctly to 11:30 AM. Typing 'date' in a command prompt confirms this as "Mon Apr 28 11:30:00 EDT 2008"

Now, given the following code:

public class Test {
 
        public static void main(String[] args) {
                System.out.println("TimeZone: "+java.util.TimeZone.getDefault());
                System.out.println("Date: "+(new java.util.Date()));
        }
} 

If I run "java Test" the output is:

TimeZone: sun.util.calendar.ZoneInfo[id="GMT-05:00",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Date: Mon Apr 28 10:30:00 GMT-05:00 2008

but if I run "java -Duser.timezone=EST Test", the output is:

TimeZone: sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=3600000,useDaylight=true,
transitions=235,lastRule=java.util.SimpleTimeZone[id=EST,
offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,
startMode=3,startMonth=3,startDay=1,startDayOfWeek=1,startTime=7200000,
startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,
endTime=7200000,endTimeMode=0]]
Date: Mon Apr 28 11:30:00 EDT 2008

Notice in the second one the time is correctly. So my question is, why is java defaulting to GMT -0500 for EST when the system command 'date' returns the correct value? What am I missing here? Is this a case of an unpatched 2007 DST update for the machine?
[ April 28, 2008: Message edited by: Scott Selikoff ]

[Marilyn de Queiroz]

Which version of java are you using? Timezone stuff was changed last year and only the newer versions have that built in. Otherwise, you'll probably need to run a patch. Is it Sun's java? or IBM's java? or ...?

[Scott Selikoff]

Java 1.4.2_06

[Jim Yingst]

Well, that is an older system, and time zone data has changed since then, including in the US. For the date you're looking at, I don't see how older time zone data would be a problem, but what they heck, it might. If you can't upgrade the JVM itself you can update the time zone data using Sun's time zone update tool.

If that doesn't work, it might be useful to know what system properties you do have set that relate to time zone. However I'm not really aware of how OpenSuse works in this respect, so I probably can't offer any insight that's not available to you by looking at them yourself.

[Marilyn de Queiroz]

I think that you either need the fix Jim suggested or upgrade to jdk 1.4.2_14 (or higher) to see if the timezone changes are affecting your app.

[Tim Holloway]

Aside from the obsolete timezone data in the older JDK, another compelling reason to upgrade is that there are some serious security concerns addressed in later releases.

One might think that timezone information is relatively static, but I get updates for the Linux TZDATA package at least once a month.

I hard to install the DST update in my cellphone (WM5). It didn't work. I had to download and install an update to the update. Good old Microsoft!

[Vilmantas Baranauskas]

Both times are the same. Look at this difference:

1) dstSavings=0,useDaylight=false
2) dstSavings=3600000,useDaylight=true

GMT has no dayligth saving therefore GMT-05 looks correct.

[Scott Selikoff]

I checked out other JVMs, 1.4.2_6 and 1.5.0_015 use EST (-0500) while 1.6.0 uses EDT (-0400). The computer is set to use daylight savings time (and it correctly does elsewhere) I'm just surprised these older versions of java are picking this up incorrectly from the system.

[Jim Yingst]

[Vilmantas Baranauskas]: Both times are the same.

Both times mean the same thing, but Scott still has a preference about which time zone should be used for displaying date/times, and that is not the same.

[Scott Selikoff]

It's more than a display issue though, I have user customizable daily schedules (such as 4pm-6pm daily) that uses time zone information to compute the actual date/times. Granted I could add time zone into the scheduling module but right now time support multiple time zones is not a requirement.

[Jim Yingst]

Understood. For what it's worth, you can also call TimeZone.setDefault() to change this within the Java program. I agree that the JVM should pick this up from the system settings, and I don't know why it's not. But the option is there to override if you need it.

[Marilyn de Queiroz]

For what it's worth, some 3 letter timezones are deprecated. "EST" is one of the affected ones.

[Jim Yingst]

Really, all three-letter time zones are deprecated as far as the TimeZone class is concerned, and have been since that class was created. Except that the API is kind of vague about it. I have to think that "GMT" and "UTC" are safe, but others are unreliable. And frankly it's pretty illogical to explicitly ask for EST and get EDT. It's much more profoundly wrong when you ask for MST and get MDT, since there are places that actually use proper MST in the summer, and it's utterly wrong for Java to assume MDT in this case. So basically, don't trust three-letter time zone IDs as they are inherently evil. The bug that Marilyn refers to was a more specific problem that affected three particular time zones, making their behavior inconsistent with the previous behavior. Which as far as I'm concerned was wrong to begin with, particularly for MST, but Sun apparently needs to be backwards compatible in their wrongness, and people who were wrongly using three-letter codes got bit by this change in behavior.

Anyway, if you've got a modern JVM, or have patched your JVM with Sun's time zone updater, then the particular bug Marilyn refers to should be fixed. But three-letter codes remain unreliable in general. I recommend you use a zoneinfo TZ code, as from this list. Eastern Time in US would be America/New_York, which is either EST or EDT depending on the time of year.
[ April 30, 2008: Message edited by: Jim Yingst ]