Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Possible bug in Calendar

Reply
Thread Tools

Possible bug in Calendar

 
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-27-2008
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.
 
Reply With Quote
 
 
 
 
Mark Thornton
Guest
Posts: n/a
 
      10-27-2008
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
 
Reply With Quote
 
 
 
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      10-27-2008
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
 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-27-2008
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.
 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-27-2008
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?)
 
Reply With Quote
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      10-27-2008
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
 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      10-27-2008
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.
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      10-27-2008
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.


 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      10-27-2008
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-28-2008
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[BUG] Ruby 1.9.0: possible bug when subclassing BasicObject Michael Fellinger Ruby 3 12-27-2007 04:05 PM
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
possible calendar bug Abraham Andres Luna ASP .Net Web Controls 1 10-26-2006 12:12 PM
Possible Bug In the Calendar Control on web forms. =?Utf-8?B?TWFyaWFubyBQYWRpbGxh?= ASP .Net 2 01-28-2006 04:37 PM
Re: Possible fix for Bug 494589 - os.path.expandvars bug Steve Holden Python 1 07-02-2003 09:42 PM



Advertisments