• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Timezone Coneversion Problem

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Rancher
Posts: 43028
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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"
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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 ]
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic