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.
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..
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.
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.