SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Jeff Verdegan wrote:They'll all have a getTime() of 1327088453960.
Dates don't have a TZ. The TZ only matters when you display a date/time.
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.
Dates don't have a TZ. The TZ only matters when you display a date/time.
What do you mean?
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
SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
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.
SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
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.
But anyway let me explain more to you.
The code I provided above solves the issue.
Amandeep Singh wrote:The code I provided above solves the issue. I'm not getting your point.
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.
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().
SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Jeff Verdegan wrote:The TZ setting on Calendar is weird. It's not intuitive what it's for.
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.
SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
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?
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?
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.
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.
SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
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.
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.
Amandeep Singh wrote:Thanks Paul. If I've to account for Day light savings, see below I'm using getOffset.
Amandeep Singh wrote:Thanks Paul. If I've to account for Day light savings, see below I'm using getOffset.
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