Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Beginning Java and the fly likes TimeZone, calendar Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "TimeZone, calendar " Watch "TimeZone, calendar " New topic
Author

TimeZone, calendar

Brian Ata
Greenhorn

Joined: May 22, 2010
Posts: 27
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:



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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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
Greenhorn

Joined: May 22, 2010
Posts: 27
I was experimenting further more, what I tried was:



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
Greenhorn

Joined: May 22, 2010
Posts: 27
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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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
Greenhorn

Joined: May 22, 2010
Posts: 27
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
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14116
    
  16

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:



Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Roberta Fine
Greenhorn

Joined: Apr 23, 2013
Posts: 27
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:
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:
OR
You can instantiate an OBJECT of the GregorianCalendar class by using the "new" keyword:
EXAMPLE:
OR


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:


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


Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7709
    
  20

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.


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: TimeZone, calendar