«

Calendar calendar = Calendar.getInstance();
calendar.set(2003,9,10,13,8,42);
Date date = calendar.getTime();



When the above code is run twice with some time passing in between, the
resulting Date objects compare unequal!


The getTime methods returned the following values from two runs of the
above code:

1065805722140
1065805722828

As you can see, the last three digits appear to vary randomly.


Clearly, this should not be the case. Calling calendar.set with the
maximal precision (six values) should completely determine the resulting
Date object. It looks like it uses the last three digits of the current
millisecond value of the system clock to "fill in the blanks" when it
really ought to use zeros.

Harold Yarmouth wrote:
> Calendar calendar = Calendar.getInstance();
> calendar.set(2003,9,10,13,8,42);
> Date date = calendar.getTime();
>
>
>
> When the above code is run twice with some time passing in between, the
> resulting Date objects compare unequal!
>
>
> The getTime methods returned the following values from two runs of the
> above code:
>
> 1065805722140
> 1065805722828
>
> As you can see, the last three digits appear to vary randomly.
>
>
> Clearly, this should not be the case. Calling calendar.set with the
> maximal precision (six values) should completely determine the resulting
> Date object. It looks like it uses the last three digits of the current
> millisecond value of the system clock to "fill in the blanks" when it
> really ought to use zeros.

The JDK documentation says this:

"Sets the values for the fields YEAR, MONTH, DAY_OF_MONTH, HOUR, MINUTE,
and SECOND. Previous values of other fields are retained. If this is not
desired, call clear() first."

So the behaviour you have noted is by design.

Mark Thornton

Mon, 27 Oct 2008 16:42:21 -0400, /Harold Yarmouth/:

> Calendar calendar = Calendar.getInstance();
> calendar.set(2003,9,10,13,8,42);
> Date date = calendar.getTime();
>
> When the above code is run twice with some time passing in between, the
> resulting Date objects compare unequal!

I think it is o.k. as you're not setting the field for the
milliseconds which is left at what it got set during the time of the
calendar construction. The documentation for the Calendar.set(int,
int, int, int, int, int) method
<http://java.sun.com/javase/6/docs/api/java/util/Calendar.html#set%28int,%20int,%20int,%20int,%20in t,%20int%29>
says:

> Sets the values for the fields YEAR, MONTH, DAY_OF_MONTH, HOUR,
> MINUTE, and SECOND. Previous values of other fields are retained.
> If this is not desired, call clear() first.

So you may either call clear() or set(MILLISECOND, 0):

Calendar calendar = Calendar.getInstance();
calendar.clear();
calendar.set(2003,9,10,13,8,42);
Date date = calendar.getTime();
System.out.println(date.getTime());

calendar = Calendar.getInstance();
calendar.set(Calendar.MILLISECOND, 0);
calendar.set(2003,9,10,13,8,42);
Date date2 = calendar.getTime();
System.out.println(date2.getTime());

System.out.println(date.equals(date2));

--
Stanimir

Mark Thornton wrote:
> The JDK documentation says this:
>
> "Sets the values for the fields YEAR, MONTH, DAY_OF_MONTH, HOUR, MINUTE,
> and SECOND. Previous values of other fields are retained. If this is not
> desired, call clear() first."
>
> So the behaviour you have noted is by design.

Nope.

If Calendar lacks a hidden, seventh milliseconds field, the six-argument
set method sets all of the fields and retains no old values, contrary to
what's observed.

If, on the other hand, Calendar has a hidden, seventh milliseconds
field, since this value is not being set by the second call to set, it
should retain the previous value, i.e. the value it had when the first
Date object was constructed. The second Date value should therefore have
the same milliseconds last-three-digits as the first Date value, again
contrary to what's observed.

So, this still looks like a bug to me.

Stanimir Stamenkov wrote:
> Mon, 27 Oct 2008 16:42:21 -0400, /Harold Yarmouth/:
>
>> Calendar calendar = Calendar.getInstance();
>> calendar.set(2003,9,10,13,8,42);
>> Date date = calendar.getTime();
>>
>> When the above code is run twice with some time passing in between,
>> the resulting Date objects compare unequal!
>
> I think it is o.k. as you're not setting the field for the milliseconds

If there is such a field, it should either be zero or the
previously-used value, not something random.

I have the feeling that Calendar.getInstance() is not returning a
singleton, and that it is also not zeroing out newly-created instances.

(And since Calendar is really a mutable Date mainly used to get
immutable Dates, perhaps they should have called it DateBuilder?)

Mon, 27 Oct 2008 17:26:40 -0400, /Harold Yarmouth/:
> Stanimir Stamenkov wrote:
>> Mon, 27 Oct 2008 16:42:21 -0400, /Harold Yarmouth/:
>>
>>> Calendar calendar = Calendar.getInstance();
>>> calendar.set(2003,9,10,13,8,42);
>>> Date date = calendar.getTime();
>>>
>>> When the above code is run twice with some time passing in between,
>>> the resulting Date objects compare unequal!
>>
>> I think it is o.k. as you're not setting the field for the milliseconds
>
> If there is such a field, it should either be zero or the
> previously-used value, not something random.

Nope, it is not random. Calendar.getInstance()
<http://java.sun.com/javase/6/docs/api/java/util/Calendar.html#getInstance()>:

> ... The Calendar returned is based on the current time...

So you're ending up with a calendar with milliseconds set based on
the current time.

Mon, 27 Oct 2008 17:26:40 -0400, /Harold Yarmouth/:

> I have the feeling that Calendar.getInstance() is not returning a
> singleton, and that it is also not zeroing out newly-created instances.

It is not returning a singleton for sure, why should it? There's no
mention for a singleton in the documentation nor it sounds logical
to be the case as you're probably realizing next.

> (And since Calendar is really a mutable Date mainly used to get
> immutable Dates, perhaps they should have called it DateBuilder?)

--
Stanimir

Stanimir Stamenkov wrote:

> It is not returning a singleton for sure, why should it? There's no


Yeah, not a singleton. It's just a plain old factory method.

Harold Yarmouth wrote:
> Mark Thornton wrote:
>> The JDK documentation says this:
>>
>> "Sets the values for the fields YEAR, MONTH, DAY_OF_MONTH, HOUR,
>> MINUTE, and SECOND. Previous values of other fields are retained. If
>> this is not desired, call clear() first."
>>
>> So the behaviour you have noted is by design.
>
> Nope.

Yep.

>
> If, on the other hand, Calendar has a hidden, seventh milliseconds
> field, since this value is not being set by the second call to set, it
> should retain the previous value, i.e. the value it had when the first
> Date object was constructed.

Calendar.getInstance() returns a Calendar representing "now", so each time
it's called you will see a different milliseconds value. To get the
behavior you're looking for, you need

Calendar calendar = Calendar.getInstance();
calendar.set(2003,9,10,13,8,42);
calendar.set(Calendar.MILLISECOND, 0);

Yes, this is obnoxious.

Stanimir Stamenkov wrote:
>
>> I have the feeling that Calendar.getInstance() is not returning a
>> singleton, and that it is also not zeroing out newly-created instances.
>
> It is not returning a singleton for sure, why should it? There's no
> mention for a singleton in the documentation nor it sounds logical to be
> the case as you're probably realizing next.
>

Given that Calendar is not thread safe and that users might wish to use
Calendar objects concurrently in different threads it would be broken if
it were a singleton.

Mark Thornton

Harold Yarmouth wrote:
> Mark Thornton wrote:
>> The JDK documentation says this:
>>
>> "Sets the values for the fields YEAR, MONTH, DAY_OF_MONTH, HOUR,
>> MINUTE, and SECOND. Previous values of other fields are retained. If
>> this is not desired, call clear() first."
>>
>> So the behaviour you have noted is by design.
>
> Nope.
>
> If Calendar lacks a hidden, seventh milliseconds field, the six-argument
> set method sets all of the fields and retains no old values, contrary to
> what's observed.
>
> If, on the other hand, Calendar has a hidden, seventh milliseconds
> field, since this value is not being set by the second call to set, it
> should retain the previous value, i.e. the value it had when the first
> Date object was constructed. The second Date value should therefore have
> the same milliseconds last-three-digits as the first Date value, again
> contrary to what's observed.

Why should a second object inherit a value from the first object ??

Arne