aspose file tools*
The moose likes Java in General and the fly likes Timezone Coneversion Problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Timezone Coneversion Problem" Watch "Timezone Coneversion Problem" New topic
Author

Timezone Coneversion Problem

Manish Jain
Ranch Hand

Joined: Jun 07, 2005
Posts: 30
Hi,
I am working on a project which has to be deployed on multiple locations around the US, so our appplication should support multiple timezones and day light saving(DST). Can some one help me out on that.

I have started using the simpleDateFormat and then setting the timezone and the conversion gives me the String belong the diggrent timezone. But when i convert it to java.util.Date it again converts back to default timezone date. The code is like that:


Now, later I came to know that java.util.date always takes the default timezone.

Can someone please help me inthis regard that what kind of strategy we use for zone coversion.

Also can some help me what is JODA is for, Is it something related to timezone conversion.

Thanks
Manish Jain
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41885
    
  63
This may be easier to debug if you actually include the timezone in the output, e.g. "EEE MMM dd HH:mm:ss yyyy zz"


Ping & DNS - my free Android networking tools app
Scott Escue
Ranch Hand

Joined: Jan 20, 2005
Posts: 34
Manish,

I'm having a little bit of trouble following what you say is happening. If I understand correctly you're saying the method you posted is working as you expect, so when you print the result of your format you get the correct MST time.
But when you parse the result of this formatted string back into a Date object and then print the Date, you get the time from your timezone. Is that correct?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Manish]: Now, later I came to know that java.util.date always takes the default timezone.

Not really. It's true only for the deprecated methods, and for toString(). Don't use the deprecated methods, especially if you are working with different timezones. And don't worry about what toString() says - yes, it uses the default time zone, but you can always use a DateFormat to display the time using a different time zone.

Using three-letter time zone abbreviations like "MST" is a bad idea for two reasons. One reason is decribed in the API for TimeZone.getTimeZone() - I'll let you read it. The other is that MST, by definition, means you are not using daylight savings. The S is for Standard, as opposed to MDT which is Mountain Daylight Time. If you ask for MST in spring or summer, that's wrong (unless you're in Arizona). Most of the time you shouldn't try to say whether it's daylight savings time or not - you should let the TimeZone and DateFormat figure it out for you.

So, if you shouldn't use names like "MST" to look up a TimeZone, what should you use? Unfortunately Java does a very poor job of documenting this. I recommend using this list - pick a name from the third column, labeled "TZ". So "MST" should probably be Mountain Time, which is probably best represented by "America/Denver". Unless you're really using Mountain Standard Time, which is "America/Phoenix". Unless it's Mauritanian Standard Time or Morroccan Standard Time or something else. This is the other reason why three-letter time zone abbreviations are evil and should be shunned.

You can also get a list of all available time zones in your JDK:

There are several overlapping naming schemes available here to choose from. I prefer the ones that match the TZ table I linked to earlier.
[ April 19, 2007: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Mike Broadbear
Ranch Hand

Joined: Jan 14, 2002
Posts: 39
If I am in Britain, and I do the following:



Will dateString contain the date in Praque local time, properly accounting for DST?

...Mike
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
It should, yes.

Incidentally, using Calendar.getInstance().getTime() is kind of the long way to create a Date representing the current time. Simply calling new Date() has the same effect, with less work for the processor. The Calendar class is fairly big, ugly, and complex, and I generally have a habit of not using it unless I need it.
 
jQuery in Action, 2nd edition
 
subject: Timezone Coneversion Problem