This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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 ]
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
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
Joined: Jul 22, 2000
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.
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.
Joined: Jan 30, 2000
[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.
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.
Joined: Jan 30, 2000
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.
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 ]