• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to revert back to original TimeZone  RSS feed

 
Simpson Kumar
Ranch Hand
Posts: 261
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

For updating a date in the DB, we need to follow the TimeZones. i.e. assume a date (2008-03-28 10:12:56) in DB is GMT TimeZone and the application is running in CST (-4 hrs difference from GMT), when we retrive the time from DB, we need to display that in CST zone, i.e the date on UI would be like 2008-03-28 6:12:56 (-4 diff). Yes I wil be able to convert into CST and display. see the following code


by calling the above method like getDateInTimeZone(dbDate, "CST"); I'll be able to convert into CST.

Whne the UI user modified the date from (2008-03-28 6:12:56) to (2008-03-28 6:12:57) (1 sec change only), then we need to convert CST time (2008-03-28 6:12:57) to GMT time (2008-03-28 10:12:57).
By calling the same method to revert back to GMT, the time is converting like (2008-03-28 14:12:57) which is wrong, because the the time is increasing by hours of 4.

How to revert back to original time zone?
 
jittu goud
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
used the SimpleDateFormat and setTimeZone() method to print it to appropriate timezone you want ....

 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, I agree with the post from jittu goud. Fundamentally, a Date object does not contain any time zone information, and shouldn't. Yes, if you make the mistake of using the default toString() method, that will use default time zone info. Ignore it, as it is fundamentally evil for anyone writing an application that will EVER be used in a different time zone.
Sudhakar Kumar wrote:the application is running in CST (-4 hrs difference from GMT)

That might be true if CST == Cuba Standard Time. Which is equivalent to Central Standard Time in the rest of North America. But if you meant CST == Central Standard Time (as used by English-speakers in North America), then the reality is that CST is equivalent to GMT-6. In the "summer" (a very loosely defined concept, here, but it includes Right Now, as I post this) most everyone in the Central Time Zone is actually using Central Daylight Time, or CDT. That's still GMT-5. Not GMT-4.

Meanwhile, most of the people living anywhere near Greenwich, the home of GMT (by which I really mean, anywhere in the UK), are actually using British Summer Time, or BST. Which is equivalent to GMT+1. And so CDT == BST-6. (Still not a difference of 4.) And of course, people living in North America's Central Time Zone are now probably using CDT, Central Daylight Time, over roughly the same dates that the UK observes BST. CDT == CST+1, so CDT == GMT - BST-5. The dates this is in effect are subject to random changes each year by any involved nation that feels like making random idiotic changes. Or any state, province, county, reservation, or whatever political entity decides to do something totally idiotic with their timekeeping system. This is a major reason why I personally despise the whole concept of "summer time" or "daylight savings time".

Anyway, if you'd said the difference was 5 or 6, there might be some reasonable explanation for the discrepancy. But as it is, there isn't. You can't possibly be in a time zone called "CST" which is equivalent to GMT-4. I originally assumed that you were probably just confused about the correct offset from GMT. But from the code and results you've posted, it seems like the problem is deeper - like maybe your database has no idea what time zone it's really in.

So let's find out.

Where are you, really? City and country should be enough.

And what, exactly, do you get if you run this?
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!