Timezone Coneversion Problem

[Manish Jain]

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:

public static void timeConversion()
{
        java.util.Date date = new java.util.Date( );
        System.out.println("date --> "+date);
        java.text.DateFormat format = new SimpleDateFormat("EEE MMM dd   HH:mm:ss yyyy" );
         format.setTimeZone( java.util.TimeZone.getTimeZone( "MST"));
         System.out.println( format.format( date));
}

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]

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"

[Scott Escue]

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]

[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:

        String[] ids = TimeZone.getAvailableIDs();
        Arrays.sort(ids);
        for (int i = 0; i < ids.length; i++)
            System.out.println(ids[i]);

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 ]

[Mike Broadbear]

If I am in Britain, and I do the following:

DateFormat df = new SimpleDateFormat("[format string]");
df.setTimeZone(java.util.TimeZone.getTimeZone("Europe/Prague"));
String dateString = df.format(Calendar.getInstance().getTime());

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

...Mike

[Jim Yingst]

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.