aspose file tools*
The moose likes Java in General and the fly likes Timezone Issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Timezone Issues" Watch "Timezone Issues" New topic
Author

Timezone Issues

Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3697
    
    5

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:

If I run "java Test" the output is:

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


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 ]

My Blog: Down Home Country Coding with Scott Selikoff
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9043
    
  10
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 ...?


JavaBeginnersFaq
"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3697
    
    5

Java 1.4.2_06
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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.


"I'm not back." - Bill Harding, Twister
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9043
    
  10
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15629
    
  15

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!


Customer surveys are for companies who didn't pay proper attention to begin with.
Vilmantas Baranauskas
Ranch Hand

Joined: Dec 20, 2006
Posts: 89
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.


Author of <a href="http://www.newsinjector.com" target="_blank" rel="nofollow">NewsInjector</a>
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3697
    
    5

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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3697
    
    5

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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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
Sheriff

Joined: Jul 22, 2000
Posts: 9043
    
  10
For what it's worth, some 3 letter timezones are deprecated. "EST" is one of the affected ones.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Timezone Issues
 
Similar Threads
rendering calendar object
Calendar.getTime() not properly reporting DST?
Calendar returns wrong date?
Calendar.HOUR for another timezone
Daylight Saving Time in Java5