• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
reply
    Bookmark Topic Watch Topic
  • New Topic