🚀 go-pugleaf

On Mon, 05 Jan 1998 07:06:49 +0200, Mike King <mcking@icon.co.za>
wrote:

Hi,

According to the documentation and my experience, Calendar objects
work as you expected before you got the results that made you doubt
the expected behavior.  I will try and reply to what I can.

>I interpret that the calendar is used to transform a date in
>milliseconds to year month, etc and visa versa, but the calendar object
>does not behave as I expect!

Your interpretation is correct.  JDK docs state "Calendar is an
abstract base class for converting between a Date object and a set of
integer fields such as YEAR, MONTH, DAY,
HOUR, and so on. "
>
>When the following code is traced via debug, and calendarDay is
>inspected, none of the time fields have been set!
>Also b shows as false in both cases, varifying that the time fields are
>not set. The timezone line is just to check that a default timezone has
>been allocated.  It has!
>
>    Calendar calendarDay = GregorianCalendar.getInstance();

The getInstance() method was implemented in the Calendar class and by
default returns a GregorianCalendar instance.  So if you say 
	Calendar calendarDay = Calendar.getInstance(); 
you will get the same object, but more open to change (if the default
Calendar subclass changes or if you want to pass a locale parameter).

This Calendar object will be initialized with the current time (as a
Date object) and all of the fields *should* be set (and have been for
me).  The boolean flag Calendar.areFieldsSet will tell you if this is
true ( as would your test below).
>    TimeZone tz = calendarDay.getTimeZone();
>    b = calendarDay.isSet(Calendar.YEAR);
>    b = calendarDay.isSet(Calendar.WEEK_OF_YEAR);
>
>I notice that Date has a variable GregorianCalendar cal, but that the
>only method that updates it is a decremented constructor!
>
>What is the essential basic relationship and behaviour between Date and
>Calendar?  Should one replace dates by calendars, or should the date
>object be the persistent object with calendars coming and going as
>needed for transformation?

I think that we will still need both.  Calendar is more usefull for
manipulating specific time periods, such as days, months, years, but
we still need Date for manipulating milliseconds.

A Calendar contains a Date object which you can access by the
get/setTime methods.
>
>Should all the time fields be automatically set when a date in
>milliseconds is assigned to a calendar object?  

Yes.  If you pass a Date object to the Calendar.setTime() method, all
of the fields will be set.  you can also get a Date object from a
Calendar after setting all of the required fields (though you you have
to mae sure that you do set all of them).

>If not, how does one set
>them?  If they are not set, how does one use the calendar for extracting
>the Year, Month, etc?
>
>Any help will be appreciated,
>Mike King

I hope this has helped,  

Noah