TimeZone, calendar

[Brian Ata]

Hi Guys, I have a question about TimeZones as the subject suggests.
I live in Eastern Time (GMT-5), and try to convert my local calendar to some different timezone
so that I can get the date, time, weekday values for that current zone.

For experimenting I have choosen TimeZone ID as "Europe/Istanbul" for testing, here is
the code I tried:

   
TimeZone tzTarget = TimeZone.getTimeZone("Europe/Istanbul"); 
Calendar calendar = Calendar.getInstance(tzTarget);

System.out.println(calendar.getTime().toString());
int weekday = calendar.get(Calendar.DAY_OF_WEEK);
System.out.println("Weekday: " + weekday);

outputs:

Thu Jun 03 13:37:15 EDT 2010
Weekday: 5

While it should output (7 hours difference in time zones):
Thu Jun 03 20:37:15 EDT 2010
Weekday: 5

What am I doing wrong ?

[Paul Clapham]

Calendar.getTime() returns a Date, doesn't it? A Date doesn't have a time zone attached to it, so if you print it, you'll print it in your system's default time zone.

[Brian Ata]

I was experimenting further more, what I tried was:

   
Calendar cal = new GregorianCalendar(TimeZone.getTimeZone("Europe/Istanbul"));
        int hour12 = cal.get(Calendar.HOUR); // 0..11

        System.out.println("hour12 : " + hour12);
        System.out.println("Current Time : " + cal.getTime());

and the output is:

hour12 : 9
Current Time : Thu Jun 03 14:12:46 EDT 2010

My conclusion is getTime() function always returns the time in default (server) timezone, which is weird since
I passed the TimeZone info while creating the object.

[Brian Ata]

Paul Clapham wrote:Calendar.getTime() returns a Date, doesn't it? A Date doesn't have a time zone attached to it, so if you print it, you'll print it in your system's default time zone.

We posted at similar times, I saw your post after posting.
Yes, but the mechanism (calendar object) that creates the date object is fully aware of the timezone it operates and the date is has a constructor
that accepts related parameters such as hours, minutes, etc..

It is weird..

[Paul Clapham]

Brian Ata wrote:Yes, but the mechanism (calendar object) that creates the date object is fully aware of the timezone it operates and the date is has a constructor
that accepts related parameters such as hours, minutes, etc..

It is weird..

You'll need to get rid of faulty thinking like that. It isn't weird at all. Sure, the Calendar knows about time zones. But a Date object doesn't have a time zone. You seem to think that because the Date was created by a Calendar, that in some way causes the Date object to somehow know about the Calendar's time zone. No. A Date object doesn't have a time zone. It doesn't matter how it was created, it doesn't have a time zone.

You can tell by looking at the documentation for an object how it will behave. This is good for programming because it makes things simpler. For example a Date doesn't know anything about time zones, and you can tell this by looking at the documentation. Imagine a language where a Date might know about time zones if it had been created by a Calendar object, but not otherwise. That would be horrendously complicated. But fortunately it isn't like that. If we have a Date object, we don't care what created it or how.

[Brian Ata]

Paul Clapham wrote:
You'll need to get rid of faulty thinking like that. It isn't weird at all. Sure, the Calendar knows about time zones. But a Date object doesn't have a time zone. You seem to think that because the Date was created by a Calendar, that in some way causes the Date object to somehow know about the Calendar's time zone. No. A Date object doesn't have a time zone. It doesn't matter how it was created, it doesn't have a time zone.

You can tell by looking at the documentation for an object how it will behave. This is good for programming because it makes things simpler. For example a Date doesn't know anything about time zones, and you can tell this by looking at the documentation. Imagine a language where a Date might know about time zones if it had been created by a Calendar object, but not otherwise. That would be horrendously complicated. But fortunately it isn't like that. If we have a Date object, we don't care what created it or how.

That is exactly what I am doing.
You should start asking the question what is a date object is for, and according to the documentation:

"The class Date represents a specific instant in time, with millisecond precision. "

Since as you underlined date does not support timezone, and nobody is asking anything about timezones, or time zone
related information from the date object. This responsibility is delegated to the calendar object.

Now the calendar object exactly knows the time zone I am interested in, so when I ask for the time, it should
get me the time in the timezone I created it to work with. The date object is just the messenger, whose whole
purpose in this context is to carry the specific instant time back to me, which it does but the time is wrong since
the calendar object behaves weird and creates a date object most probably with the default constructor,
instead of the overloaded one that accepts hrs, min etc.

I hope I am more clear now..
Thank you for your time.

[Jesper de Jong]

The java.util.Date class in Java is very simple - it is not much more than a wrapper for a 64-bit value that contains the number of milliseconds since 1 January 1970, 00:00:00 UTC. As has been argued, it doesn't do anything with timezones, no matter if it was created by class Calendar, which does know about timezones, or some other way. You should regard a Date object as containing an "absolute" moment in time - independent of timezones.

When you want to display a date, it has to be converted to a string. It is during this conversion that you need to know a timezone, because otherwise you wouldn't know what hours etc. to display.

When you directly convert a Date object to a string by calling toString() on it (implicitly or explicitly), it will be formatted with some default format and using the default time zone of the system that the program is running on. Note that it uses the default time zone, because the Date object itself simply does not contain any timezone information (no matter where the Date object came from).

If you want to display the date in a specific timezone, you'd have to use a DateFormat object (which is responsible for converting Date objects to strings), and specify in which timezone you want to display the date by setting the timezone on the DateFormat object. For example:

// Get a Date object which represents the current moment in time
Date now = new Date();

// Create a DateFormat and set the timezone that you want to display dates in
DateFormat df = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss Z");
df.setTimeZone(TimeZone.getTimeZone("Europe/Istanbul"));

// Prints the date and time in the specified timezone
System.out.println(df.format(now));

[Roberta Fine]

I found Jasper de Jong's answer and code above to be a very clear example of the relationships between the java.util.Date, java.util.Calendar and java.util.GregorianCalendar classes.
In my studying of these closely, I found the following:

1. Date Class is mainly for a current timestamp using SimpleDateFormat to manage the time display:
EXAMPLE:

SimpleDateFormat myDateFormat = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss z");

Also, as of JDK 1.1, the Date Class was not amenable to internationalization, and many methods are deprecated.
So, use Calendar Class to convert between dates and time fields.

2. Calendar Class is an abstract encapsulation of OBJECT Date and cannot be instantiated.
GregorianCalendar Class is a CONCRETE IMPLEMENTATION or SUBCLASS of Calendar and is used to create an OBJECT.

3. You can use the getInstance() method of the Calendar Class to return an OBJECT of the GregorianCalendar Class.
EXAMPLE:

Calendar myCalendar = Calendar.getInstance();

OR
You can instantiate an OBJECT of the GregorianCalendar class by using the "new" keyword:
EXAMPLE:

Calendar myCalendar = new GregorianCalendar(); 

OR

GregorianCalendar myCalendar = new GregorianCalendar();

4. An important point is that there are CONSTANT FIELDS already assigned to the Calendar class.
Example is HOUR = 10. ( SEE http://docs.oracle.com/javase/6/docs/api/constant-values.html)
So, to get the CURRENT HOUR, TIME, etc... you must use the Calendar class name with the GET and SET methods.
EXAMPLE:

Calendar myCalendar = new GregorianCalendar();
     int hour, minute;
     // GET METHODS
     hour = myCalendar.get(Calendar.HOUR_OF_DAY);
     minute = myCalendar.get(Calendar.MINUTE);

Otherwise, you will display the value already set as a CONSTANT FIELD.

[Winston Gutkowski]

Brian Ata wrote:Now the calendar object exactly knows the time zone I am interested in, so when I ask for the time, it should
get me the time in the timezone I created it to work with. The date object is just the messenger, whose whole
purpose in this context is to carry the specific instant time back to me, which it does but the time is wrong since
the calendar object behaves weird and creates a date object most probably with the default constructor,
instead of the overloaded one that accepts hrs, min etc.

Like everybody has been trying to tell you, it's your interpretation that's wrong, not Java's. The classes you're using are behaving exactly as they are documented to.

You may find that ABriefHistoryOfJavaTime clarifies things for you a bit.

The fact is that the whole Calendar/Timezone thing is a red herring because it's NOT the class you should be using. As Jesper showed you, you should be using SimpleDateFormat.

Winston

[Edit] Ooops. Just realised that this thread was from a long time ago. However, I leave my post here in case it helps anyone else.