Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Possible bug in Calendar

 
 
Wojtek
Guest
Posts: n/a
 
      10-28-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.


calendar.getTime() always returns the current time regardless of the
value wihin the Calendar object.

Yes, this is a pain.

--
Wojtek


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-28-2008
Harold Yarmouth wrote:
> 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.


Have you read the documentation ?

http://java.sun.com/javase/6/docs/ap.../Calendar.html

public static Calendar getInstance()

Gets a calendar using the default time zone and locale. The
Calendar returned is based on the current time in the default time zone
with the default locale.

The keywords are "current time".

And even though a singleton implies a getInstance method, then a
getInstance method does not imply a singleton.

Arne
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-28-2008
Wojtek wrote:
> calendar.getTime() always returns the current time regardless of the
> value wihin the Calendar object.


It does not. It returns value within the Calendar object.

Arne
 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      10-28-2008
Arne Vajh°j wrote :
> Wojtek wrote:
>> calendar.getTime() always returns the current time regardless of the value
>> wihin the Calendar object.

>
> It does not. It returns value within the Calendar object.
>
> Arne


Sigh.

My opinion was based on a series of test I did when I was using an
earlier Java version. I could never get the Calendar object to return
the date within it. It always seemed to return the current time rather
than the set time.

And now a quick test shows it returns the Calendar time.

I remember this specifically as I was getting quite frustrated with it.

--
Wojtek


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      10-28-2008
Wojtek wrote:
> Arne Vajh°j wrote :
>> Wojtek wrote:
>>> calendar.getTime() always returns the current time regardless of
>>> the value wihin the Calendar object.

>>
>> It does not. It returns value within the Calendar object.
>>
>> Arne

>
> Sigh.
>
> My opinion was based on a series of test I did when I was using an
> earlier Java version. I could never get the Calendar object to
> return
> the date within it. It always seemed to return the current time
> rather
> than the set time.
>
> And now a quick test shows it returns the Calendar time.
>
> I remember this specifically as I was getting quite frustrated with
> it.


A newly created Calendar contains the current time. Perhaps your test
was inadvertently creating a new Calendar object and doing the
getTime() on that?


 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-28-2008
Mike Schilling wrote:
> 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.


Nope. Or, at least, not what was implied elsewhere.

> Calendar.getInstance() returns a Calendar representing "now", so each time
> it's called you will see a different milliseconds value.


Well, there's the problem, right there. Most other places, having a
no-arguments "getInstance" method instead of a constructor means some
sort of singleton. (Although I can see why this wouldn't work for
Calendar, which is mutable; it wouldn't be thread-safe.)

It leads one to expect that any milliseconds value wouldn't be changing.
 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-28-2008
Arne Vajh°j wrote:
> Why should a second object inherit a value from the first object ??


That depends on there being a second object. Ordinarily, having no
constructor but a no-arguments "getInstance" method signals a singleton,
or something with singleton-like behavior (such as one instance per
calling thread).
 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-28-2008
Stanimir Stamenkov wrote:
> So you're ending up with a calendar with milliseconds set based on the
> current time.


Why is the "most specific" set method missing a field for this? And
surely it should set that field to zero, since there's no reason to set
everything else but have those last three digits vary randomly.


> It is not returning a singleton for sure, why should it?


It shouldn't, but having no public constructor and having instead a
no-arguments "getInstance" method suggests it, or a similar thing such
as fetching a per-thread instance.
 
Reply With Quote
 
Harold Yarmouth
Guest
Posts: n/a
 
      10-28-2008
Arne Vajh°j wrote:
> Harold Yarmouth wrote:
>> 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.

>
> Have you read the documentation ?


Have you forgotten yet again to check your confrontational attitude at
the door?

> And even though a singleton implies a getInstance method, then a
> getInstance method does not imply a singleton.


It usually implies something of the sort, if it takes no arguments and
there's no public constructor. In this case, a per-thread instance might
have made sense. With the semantics of producing a new instance every
time, there's no apparent reason not to have a public constructor.

To be more exact, use of a factory method instead of any public
constructors usually means one of two things: the exact type is dynamic
(and why would it be in this case?) or it may return a pre-existing
instance.

Since there's no obvious reason for polymorphism here (any
locale/timezone stuff can be done by way of private fields and
delegation, with generic behavior) that leaves pre-existing instances.
Or perversity, I suppose.
 
Reply With Quote
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      10-28-2008
Tue, 28 Oct 2008 02:42:21 -0400, /Harold Yarmouth/:
> Stanimir Stamenkov wrote:
>
>> So you're ending up with a calendar with milliseconds set based on the
>> current time.

>
> Why is the "most specific" set method missing a field for this? And
> surely it should set that field to zero, since there's no reason to set
> everything else but have those last three digits vary randomly.


Whether the "most specific" method should automatically set the
milliseconds to 0 is subjective. Probably many would come up with
cases they would not want that method doing so. At least the
present behavior is ever since the Calendar has been introduced
(Java 1.1), thus changing it would break existing applications. You
can only hope an even more specific method will be introduced in
future Java versions, but I don't think it worths it.

>> It is not returning a singleton for sure, why should it?

>
> It shouldn't, but having no public constructor and having instead a
> no-arguments "getInstance" method suggests it, or a similar thing such
> as fetching a per-thread instance.


You've already been given the most exact answer by Mark Space: "It's
just a plain old factory method."

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