aspose file tools*
The moose likes Java in General and the fly likes Change Timezone from GMT to EST, the best way to accomplish? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Change Timezone from GMT to EST, the best way to accomplish?" Watch "Change Timezone from GMT to EST, the best way to accomplish?" New topic
Author

Change Timezone from GMT to EST, the best way to accomplish?

Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
See the below code how I am converting from EST to GMT. Note the time and date difference. Ignore the timezone ID since calling getTime() would always fetch time in current timezone which can never be changed only day/hours can be changed.

Let me know if this is correct way or it do have unknown bugs in there. Please don't mention about JODA library since I cannot use it.



SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

No. If I am in London, and you are in Tokyo, and our friend is in Chicago, and we all create a Date object at the same instant, right now, all 3 Date objects will be the same. They'll all have a getTime() of 1327088453960. Dates don't have a TZ. The TZ only matters when you display a date/time. 4PM in New York IS the same time as 1PM in Los Angeles. So if you want to display a particular date/time in a particular TZ, you call SimpleDateFormat's setTimeZone() method.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Jeff Verdegan wrote:They'll all have a getTime() of 1327088453960.

That's not true if run above example, you will see following output-

In below output although timezone is same. But 2nd time is different because it's GMT date time.



Dates don't have a TZ. The TZ only matters when you display a date/time.

What do you mean?

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Amandeep Singh wrote:
Jeff Verdegan wrote:They'll all have a getTime() of 1327088453960.

That's not true if run above example, you will see following output-

In below output although timezone is same. But 2nd time is different because it's GMT date time.



No, you're mistaken. You're not understanding what you're seeing/doing.

Set your computer's TZ to EST, then call new Date().getTime() or System.currentTimeMillis(). Then set it to GMT or JST and call new Date().getTime() again. You'll see that the values are the same, except for the difference of a few minutes that it took you to make the change and run the code again.



Dates don't have a TZ. The TZ only matters when you display a date/time.

What do you mean?



I mean exactly what I said: When you create a java.util.Date object, it does NOT carry any notion of your TZ. A Date object represents an instant in time. The TZ only comes into it when we want to display that Date. Fri Jan 20 14:45:51 EST 2012 and Fri Jan 20 19:45:51 GMT 2012 are the same instant in time. We're just displaying it differently.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Study the following. Note that we are using the same Date object for all printouts. That Date object is not being changed at all. We are merely formatting it differently. The same Date object represents all 3 times because (X):00 in EST IS THE SAME TIME as (X-3):00 in PST, etc.

Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
No, you're mistaken. What you're seeing above is the exact same Date object, formatted two different ways, due to one DateFormat object having one TZ and the other DateFormat having a different TZ


Sorry I must be missing some point. It's not the same Date object. But anyway let me explain more to you.

We are receiving GMT time and we do live in EST zone. When we receive the time, there is an offset since our system will do the conversion to EST. As a user I don't care about timezones so the date/time what GMT people do see and EST folks should also see same date/time.
The code I provided above solves the issue. I'm not getting your point.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Jeff Verdegan wrote:Study the following. Note that we are using the same Date object for all printouts. That Date object is not being changed at all. We are merely formatting it differently. The same Date object represents all 3 times because (X):00 in EST IS THE SAME TIME as (X-3):00 in PST, etc.



By looking at this example, it defnitiely makes sense. Since setting timezone on Calendar makes no difference, it would always gettime in EST. Not sure if this is a potential bug in Calendar object.
Setting timezone onn dateformat do definitely shows the change.

Thanks for clearing.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Another my point, it's always examples and words make more sense to me rather than just words. I believe this may apply to most people.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

EDIT: The following may be unnecessary, as you seem to now understand what I've been saying.

Amandeep Singh wrote:
No, you're mistaken. What you're seeing above is the exact same Date object, formatted two different ways, due to one DateFormat object having one TZ and the other DateFormat having a different TZ


Sorry I must be missing some point. It's not the same Date object.


Yes, you are missing a point. But I also didn't look closely enough at what you're doing.

The following is absolutely true, however: Right .... ... NOW ... ... I created a Date object. If I call getTime(), it gives me 1327090447003, the same value as if I called System.currentTimeMillis(). If, at the same instant that I created that Date object, somebody in Chicago, somebody in Tokyo, and somebody in London all created a Date object, they would all have the exact same value: 1327090447003. (Assuming, of course, their computers' TZs and clocks were set correctly.)

1327090447003 IS the Date object for 3:15 PM today EST, and it IS the Date object for 1:15 PM PST today.

But anyway let me explain more to you.


No. Please understand: You are mistaken. I will not spend any more time trying to convince you. Either study my comments and my code carefully, and come to understand how Dates and TZs work in Java, or continue with your approach, which is based on faulty assumptions.

The code I provided above solves the issue.


No, it only appears to. The Date object does not have a time zone.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Amandeep Singh wrote:The code I provided above solves the issue. I'm not getting your point.


If you want to convert between GMT and some other timezone which doesn't have daylight saving time, then yeah, your code is a hacky way to fake it. And I say "Hacky" and "Fake" because that's what it is. It isn't going to work with a timezone which does have daylight saving time and you won't be able to make it work with one either.

And if you want to get Jeff's point, then re-read what he said. It's perfectly clear and correct. Your assumptions, however, are not correct.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Amandeep Singh wrote:
By looking at this example, it defnitiely makes sense. Since setting timezone on Calendar makes no difference, it would always gettime in EST. Not sure if this is a potential bug in Calendar object.
Setting timezone onn dateformat do definitely shows the change.

Thanks for clearing.


Cool, I'm glad you understand now.

The TZ setting on Calendar is weird. It's not intuitive what it's for. I've tried playing with it a few times, and finally figured out what it means. I've never found a use for it though, and I've forgotten what it's for. I don't think it's a bug per se, I think it's just a confusing design with poor documentation.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
The following is absolutely true, however: Right .... ... NOW ... ... I created a Date object. If I call getTime(), it gives me 1327090447003, the same value as if I called System.currentTimeMillis().


Now I know why we disagreed.


I was referring to getTime() on Calendar object as first example shows and you were talking about getTime() on Date object.


The output is displayed as -


Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Jeff Verdegan wrote:The TZ setting on Calendar is weird. It's not intuitive what it's for.


Without reading the documentation, here's how I would expect it to work:

(1) I set the TZ of a Calendar object to some time zone.

(2) I add one day to the Calendar object, using the "add" method.

I would expect the code to interpret the underlying time-since-the-epoch of the Calendar in terms of that time zone, and add either 23, 24, or 25 hours to that underlying time depending on whether adding a day would cross a change between standard time and daylight saving time in that time zone.

(3) I get the "hours" component of the Calendar object, using the "get" method.

I would expect the code to interpret, etc, etc, in terms of that time zone and return the hours value according to that interpretation.

Whether the documentation says anything like that, I don't know. And I don't even know whether it actually does that -- I've never had to wade into that swamp.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Paul Clapham wrote:
Amandeep Singh wrote:The code I provided above solves the issue. I'm not getting your point.


If you want to convert between GMT and some other timezone which doesn't have daylight saving time, then yeah, your code is a hacky way to fake it. And I say "Hacky" and "Fake" because that's what it is. It isn't going to work with a timezone which does have daylight saving time and you won't be able to make it work with one either.

And if you want to get Jeff's point, then re-read what he said. It's perfectly clear and correct. Your assumptions, however, are not correct.


Paul,

Since EST do have daylight savings, do you think raw offset will always have 5 hours difference throughout the year. Won't it change with daylight savings?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Amandeep Singh wrote:
Paul Clapham wrote:
Amandeep Singh wrote:The code I provided above solves the issue. I'm not getting your point.


If you want to convert between GMT and some other timezone which doesn't have daylight saving time, then yeah, your code is a hacky way to fake it. And I say "Hacky" and "Fake" because that's what it is. It isn't going to work with a timezone which does have daylight saving time and you won't be able to make it work with one either.

And if you want to get Jeff's point, then re-read what he said. It's perfectly clear and correct. Your assumptions, however, are not correct.


Paul,

Since EST do have daylight savings, do you think raw offset will always have 5 hours difference throughout the year. Won't it change with daylight savings?


Yes, it will change. That is his point. Basically he's saying that your original method will only work if the two TZs shift into and out of DST on the same day, or both don't use DST at all. Even if they do both shift on the same day, between the time when one has shifted and the other has not (anywhere from 1 to 23 hours), your initial approach will fail.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Amandeep Singh wrote:Paul,

Since EST do have daylight savings, do you think raw offset will always have 5 hours difference throughout the year. Won't it change with daylight savings?


Well, yes I do. But I'm not the authority here, the API documentation is. And
The API documentation wrote:Returns the amount of time in milliseconds to add to UTC to get standard time in this time zone. Because this value is not affected by daylight saving time, it is called raw offset.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Thanks Paul. If I've to account for Day light savings, see below I'm using getOffset.




getOffset

public int getOffset(long date)
Returns the offset of this time zone from UTC at the specified date. If Daylight Saving Time is in effect at the specified date, the offset value is adjusted with the amount of daylight saving.
This method returns a historically correct offset value if an underlying TimeZone implementation subclass supports historical Daylight Saving Time schedule and GMT offset changes.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Amandeep Singh wrote:
Jeff Verdegan wrote:Study the following. Note that we are using the same Date object for all printouts. That Date object is not being changed at all. We are merely formatting it differently. The same Date object represents all 3 times because (X):00 in EST IS THE SAME TIME as (X-3):00 in PST, etc.



By looking at this example, it defnitiely makes sense. Since setting timezone on Calendar makes no difference, it would always gettime in EST. Not sure if this is a potential bug in Calendar object.
Setting timezone onn dateformat do definitely shows the change.

Thanks for clearing.



The only problem I do see with this code when compared to my requirement is, DateFormat output's are in String format. If I change them back to Date object, they do automatically get changed to EST zone date/time which is wrong according to my requirement. And my requirement says forget timezone, the date/time feed from GMT zone into EST zone should not change the date/time, the date/time value should remain same whether it is coming from GMT or PST to EST zone. In short I want to say, since my servers run in EST zone, even though whatever time I'm getting should remain same. I hope you get my point. That's how I've written my code. Since I deal with Date objects and it will always show date/time in EST so i said to myself forget timezone all that matters is date/time which should remain same when coming from 1st system(GMT zone) to 2nd system(EST zone). I've no need to find timezone conversions since the way Calendar object works it changes time as per timezone, I've to substract offset.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Amandeep Singh wrote:The only problem I do see with this code when compared to my requirement is, DateFormat output's are in String format. If I change them back to Date object, they do automatically get changed to EST zone date/time which is wrong according to my requirement.


If your requirement says (or implies) that you should have a Date which has a certain timezone, then your requirement is just plain wrong.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Amandeep Singh wrote:Thanks Paul. If I've to account for Day light savings, see below I'm using getOffset.


I haven't looked at your code but I'm willing to bet you're calling getOffset with the wrong timestamp, and that therefore (as Jeff already predicted) you're going to be off by an hour (or at any rate the DST offset) for certain times close to when the standard-to-daylight switch takes place.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Amandeep Singh wrote:Thanks Paul. If I've to account for Day light savings, see below I'm using getOffset.


Then you're doing it wrong. I thought you had learned from our explanations and my code.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Amandeep Singh wrote:
The only problem I do see with this code when compared to my requirement is, DateFormat output's are in String format.

That's not a problem. That's the only way it can work because DATE DOES NOT HAVE A FORMAT OR A TIMEZONE.

If I change them back to Date object, they do automatically get changed to EST zone


No, they don't. java.util.Date does not have a TZ. If you think it does because calling System.out.println(new Date()) shows EST, then you are still making a faulty assumption. When you println() a Date, it uses a SimpleDateFormat based on your computer's local TZ. The Date object does not have a TZ.

That's all. I'm done. This is what I've been telling you from the beginning, but I don't seem to be able to get you to understand it.

Good luck.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Change Timezone from GMT to EST, the best way to accomplish?