Problem with Calendar().getTime()

[Dm Laf]

Greeting everyone!

I've got this weird issue. The following piece of code outputs my local time instead of the time of the set timezone.

  
TimeZone tz = TimeZone.getTimeZone("Pacific/Wake");

System.out.println("Incorrect time(Shows my local time) --> " + Calendar.getInstance(tz).getTime());

What am I doing wrong? How could I get a calendar object (or a Date) with values set to the preferred timezone?

[Kurt Van Etten]

Hi,

The time is set correctly in your Calendar instance; it's just that when you output the time value, it is displayed according to the local time zone (e.g., your time zone).

To display the time according to the time zone you've set for the Calendar, you could use a DateFormat object and do something like the following:

import java.text.DateFormat;
import java.util.*;

public class PrintDate
{
   public static void main (String[] args)
   {
      TimeZone tz = TimeZone.getTimeZone("Pacific/Wake");

      DateFormat df = DateFormat.getDateTimeInstance();
      df.setTimeZone(tz);

      System.out.println("Current time on Wake Island --> " +
                         df.format(Calendar.getInstance(tz).getTime()));
   }
}

(Although for this particular example there is no real reason to create a Calendar object with the particular time zone; the DateFormat is doing all the work so I could just have it display the local time.)

[Dm Laf]

Hi Kurt,

First of all, I'd like to thank you for your immediate response.

Now..What I do not understand is that if the getTime() method always displays my local time, disregarding the timezone parameter in the getInstance(Timezone tz) method, then whats the point of supplying one? Is it a bug?

I dont just need to output the date..I need a calendar object because I am working on a client/server application and several components on my client need to contain the server time. These components are setting their values based on the Calendar.getTime() method. So you see where my issue is..?

Thank you,

[Rene Larsen]

The TimeZone is stored on the Calendar, but is not used if you only want the the Date by using getTime()

To use the stored TimeZone, you can do it like this - and using the DateFormat/SimpleDateFormat

DateFormat df = new SimpleDateFormat("zzzz");
Calendar cal = Calendar.getInstance();

cal.setTimeZone(TimeZone.getTimeZone("Pacific/Wake"));
df.setTimeZone(cal.getTimeZone());
System.out.println("TimeZone on Wake Island --> " + df.format(cal.getTime()));

cal.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles"));
df.setTimeZone(cal.getTimeZone());
System.out.println("TimeZone in Los Angeles --> " + df.format(cal.getTime()));

[Darryl Burke]

Dim (is Dim a first name or an adjective? ;))

You're not printing a Calendar, you're printing a Date. And Date is an encapsulation of a point in time, represented internally by a long value equal to the number of milliseconds since a certain instant of time known as the Epoch.

Now Date doesn't have a TimeZone. Date.toString(), which is what is called when you System.out.println a Date, uses a TimeZone to produce a human-readable form of the encapsulated long value. That TimeZone is your default, or local TimeZone.

You've already been given good advice about how to produce the output you want. I just thought you should also understand a little more about the often-misunderstood java.util.Date. To repeat: Date doesn't have a TimeZone. It represents a point in time, which is the same instant everywhere, whether it's dawn in New York or dusk in New Delhi.

[Dm Laf]

Thank you guys for your responses.

I think I may have been misunderstood in my original post and that is probably why every1 is giving me examples on how to output the date in different timezones.

That is NOT why I am looking an answer for. All I need to know is why Calendar.getInstance(Timezone ).getTime() ALWAYS displays my local time. I would have expected that since I am supplying a timezone, the getTime() method of the Calendar class, outputs the time for that zone.

Like I said on my second post, I have a client/server application and I need to find a way to populate fields on the client with the server calendar details. These fields (and I am not talking about plain labels or texts), accept only Calendar objects.

Thank you again for your time

PS: Darryl: " It represents a point in time, which is the same instant everywhere, whether it's dawn in New York or dusk in New Delhi." I agree. But the same instance of time in New Delhi it could be 08.00am and in Adelaide, Australia it could be 11.00am. Again, since I am supplying a timezone in the Calendar, I'd expect it would return the corresponding time.

[Mike Simmons]

Dim Stef wrote:All I need to know is why Calendar.getInstance(Timezone ).getTime() ALWAYS displays my local time.

Because Calendar.getTime() returns a Date, and you are calling the toString() method on java.util.Date. Go and read the documentation for this method. The toString() method on Date uses your local time, period. That's why you're seeing local time.

Dim Stef wrote:I would have expected that since I am supplying a timezone, the getTime() method of the Calendar class, outputs the time for that zone.

You are supplying a timezone to the Calendar, but then you are getting a Date. As Darryl correctly said in his post, a Date has no timezone of its own. Instead, the toString() method does always use local time, period.

Dim Stef wrote:Like I said on my second post, I have a client/server application and I need to find a way to populate fields on the client with the server calendar details. These fields (and I am not talking about plain labels or texts), accept only Calendar objects.

Well, you can go ahead and do that. The problem right now though is that you're trying to print the time associated with a Calendar, and you're doing it in a way that loses the time zone information. The Calendar itself may be perfectly representing what you want, but Date's toString() is giving you local time, period.

Solution: don't use Date's toString(). Ignore it. If you want to know what's in the Calendar, use the Calendar's own toString() method (which gives ugly but detailed output). Or use getTimeZone() to get the time zone, and other get() methods to get other info. And if you want to print a Date object in a particular time zone, use DateFormat as discussed above. Calling Date's toString() will never, ever do what you want here, no matter how much you think it should be otherwise.

[Dm Laf]

Thank you Mike for taking the time to answer to my question.

I totally agree with you that Date does not have a timezone, but the way I see it, if I live in Russia and I am asking Java to give me the current date in India then Calendar.getInstance(Timezone of India).getTime() should return the current time in India. Returning the local time is fundamentally incorrect. Period.

Playing with toString() methods just to get (and not output..) a time in a different timezone is just not right.

I may have to report to Oracle as an issue that require further attention.

Thank you very much for all your responses guys.

[Darryl Burke]

Dim Stef wrote:Thank you Mike for taking the time to answer to my question.

I add my thanks for expressing many of the things I said in a way more suited to the OP's understanding (no sarcasm intended)

Dim Stef wrote:I totally agree with you that Date does not have a timezone, but the way I see it, if I live in Russia and I am asking Java to give me the current date in India then Calendar.getInstance(Timezone of India).getTime() should return the current time in India.

Unfortunate for you that the way you see it isn't the way it was designed to work.

Dim Stef wrote:Returning the local time is fundamentally incorrect. Period.

You still don't get it, do you? A point in time is the same instant all over the world, all over the universe. The only thing that's incorrect here is your flawed understanding and expectations.

Dim Stef wrote:Playing with toString() methods just to get (and not output..) a time in a different timezone is just not right.

Nobody suggested playing with toString methods. The suggestions were to use the SimpleDateFormat class, which is the correct approach.

Again, a Date encapsulates a point, or an instant, in time. When it's noon in London it's 17:30 in Delhi. That instant is the same point in time. Only the representation of that instant in time changes with the timezone, not the instant itself.

Dim Stef wrote:I may have to report to Oracle as an issue that require further attention.

Sorry but

Dim Stef wrote:Thank you very much for all your responses guys.

Youre welcome? but if you fail to understand the concepts presented here, you're going to face a lot of grief down the line.

[David Newton]

Dim Stef wrote:I totally agree with you that Date does not have a timezone, but the way I see it, if I live in Russia and I am asking Java to give me the current date in India then Calendar.getInstance(Timezone of India).getTime() should return the current time in India. Returning the local time is fundamentally incorrect. Period.

I'm not sure why we're not getting through to you on this one. You're *NOT* asking Java to give you the Date in India. You're asking Java to give you the Date of a Calendar with a TZ of India, but you're still confused as to what a Date is.

Dates are UTC. Look at the Date docs. See anything about timezones? No. Think of a Date as an absolute timestamp reference, to which timezones may be applied. No matter what TZ you give a *Calendar*, the *underlying absolute moment in time* is precisely the same.

I may have to report to Oracle as an issue that require further attention.

Good luck with that!

[Darryl Burke]

David Newton wrote:I'm not sure why we're not getting through to you on this one. You're *NOT* asking Java to give you the Date in India. You're asking Java to give you the Date of a Calendar with a TZ of India, but you're still confused as to what a Date is.

Some people never get it
http://forums.sun.com/thread.jspa?threadID=5441610

[David Newton]

Holy jeebus.

[Dm Laf]

"You're *NOT* asking Java to give you the Date in India. You're asking Java to give you the Date of a Calendar with a TZ of India"... Do you hear yourself what you just said?

Please stop repeating that Date has no timestamp. I think we have established that already. I am not arguing that! What I am arguing is the following piece of code

Calendar.getInstance(IndiaTZ).getTime() = Calendar.getInstance(LondonTZ).getTime() =Calendar.getInstance(CairoTZ).getTime() <--- WRONG!

It may be the same *underlying absolute moment in time* BUT 2010/12/05 04:00PM is not the same as 2010/12/04 :00AM nor 2010/12/04 03:AM. That is my argument here. That is the reason I am asking Calendar for the DETAILS of the *underlying absolute moment in time* in different TIMEZONES! Calendar is sending me a Date object, but I expect it to be modified according to the timezone. Otherwise, what is the point of supplying a timezone to the Calendar obj?

[Paul Clapham]

Dm Laf wrote:Calendar is sending me a Date object, but I expect it to be modified according to the timezone.

Then you expect incorrectly. That has already been explained in this thread so I won't explain it again. I will just say that trying to program based on what you expect to happen, instead of based on what actually does happen, is not going to get you anywhere. In fact it's just a waste of time.

[Stephan van Hulst]

Darryl Burke wrote:Some people never get it
http://forums.sun.com/thread.jspa?threadID=5441610

Wow. I only read the first two pages, but wow.

[Mykola Makhin]

I don't understand your harshness people, you fail at explaining the issue, yet are angry at the person you're trying to explain it to.

@Dm Laf, if you're still there:
Thing is inside Date you have something similar to UNIX timestamp, i.e. number of seconds since 1-st of Jan 1900 00:00:00 GMT or something similar.
Naturally, this number is the same for every timezone.

As established already, Date has no timezone in it, so going from Calendar.getInstance(whateverTimezone).getDate() always returns the point in time when calendar was created, as a number of seconds since 1900 it will be the same number for all timezones. Thus there is no bug. Just a bad naming - Date isn't really a date, it's a timestamp.

The problem is indeed in toString() method of Date, and the problem is that it doesn't allow you to specify a timezone you want to represent date in. There's no toString(TimeZone tz) while there could be.
It's a bit silly that toString uses timezone, but always takes the default one and actually shows it (for example, for me it now returns "Tue Aug 06 14:25:44 EEST 2013", note the "EEST" part - this is my default timezone, and I can't tell Date.toString() to use any different than that).

If there would be such method as Date.toString(TimeZone tz) , Date.toString() could be implemented like "return this.toString(TimeZone.getDefault())".
Something like new String(bytes) uses default charset, while there is an alternative new String(bytes, charsetName).

But since there isn't such method, the only alternative is using DateFormat to take the Date (i.e. number of seconds since 1900) and represent it in timezone specific manner.

P.S. Perhaps I should conclude with the example of what I propose:
java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
java.util.Date now = new java.uitl.Date();
sdf.setTimeZone(TimeZone.getTimeZone("GMT+3"));
System.out.println(sdf.format(now)); // ===> 2013-08-06 15:32:45
sdf.setTimeZone(TimeZone.getTimeZone("GMT+1"));
System.out.println(sdf.format(now)); // ===> 2013-08-06 13:32:45

As you can see, I've managed to get 2 hours difference in representation of same timestamp for GMT+3 and GMT+1. Hope this help you.

[Winston Gutkowski]

Mykola Makhin wrote:I don't understand your harshness people, you fail at explaining the issue, yet are angry at the person you're trying to explain it to.

And I don't quite understand your reaction to a thread that is:
(a) nearly 3 years old.
(b) has already been responded by OP with the words "Thank you Mike for taking the time to answer to my question".

If there's any "anger", it's usually when somebody starts stating something as fact when they have already been told that what they are thinking is
(a) patently not so.
(b) the responder (especially if they are one of the Moderators here) feels that the poster has used inappropriate language or is just not "listening". After all, they came for advice, and it is irritating to feel that you're being ignored. We're all human.

FYI, I've created this page on the subject of time if you're interested. I'd be interested in your comments.

Winston