Possible bug in Calendar
Harold Yarmouth
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.
Mark Thornton
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
Stanimir Stamenkov
> 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,%20int,%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
Harold Yarmouth
> 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.
Harold Yarmouth
> 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?)
Stanimir Stamenkov
> 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
Mark Space
> 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.
Mike Schilling
> 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.
Mark Thornton
>
>> 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
Arne Vajhøj
Why should a second object inherit a value from the first object ??
Arne
Wojtek
calendar.getTime() always returns the current time regardless of the
value wihin the Calendar object.
Yes, this is a pain.
--
Wojtek :-)
Arne Vajhøj
> 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/api/java/util/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
Arne Vajhøj
> 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
Wojtek
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 :-)
Mike Schilling
> Arne Vajhřj wrote :
A newly created Calendar contains the current time. Perhaps your test
was inadvertently creating a new Calendar object and doing the
getTime() on that?
Harold Yarmouth
> 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.
Harold Yarmouth
> 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).
Harold Yarmouth
> 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.
Harold Yarmouth
> 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.
Stanimir Stamenkov
> 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
Mike Schilling
Or useful even within one thread:
Calendar cal = Calendar.getInstance();
cal.setTime(.....)
Calendar cal2 = Calendar.getInstance();
cal2.setTime(....) // D'oh!
newInstance() would be a better name.
Joshua Cranmer
> 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.
FWIW, many people would consider the Calendar API to be a shining
example of poor design.
> 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.
... You just answered your own question. Then you said "Why would it be
in this case?"
From the documentation:
Like other locale-sensitive classes, Calendar provides a class method,
getInstance, for getting a generally useful object of this type.
Calendar's getInstance method returns a Calendar object whose calendar
fields have been initialized with the current date and time.
Note that there are different Calendars: there's the Gregorian calendar,
Buddhist calendar, and Julian calendar in what I could find of my OpenJDK.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Roedy Green
<mscotts...@hotmail.com> wrote, quoted or indirectly quoted
someone who said :
>
>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.
This is not a bug because the behaviour is documented and consistent
with the documentation.
I usually call these "gotchas", but I think this sort of thing
deserves another name, something closer to "design flaw".
--
Roedy Green Canadian Mind Products
http://mindprod.com
A vote for McCain is fearful clinging to McSame.
A vote for Obama is a shot at Obamalot.
Lew
> So you may either call clear() or set(MILLISECOND, 0):
Problem with clear() is that it leaves the calendar in an inconsistent state.
It "[s]ets the given calendar field value and the time value (millisecond
offset from the Epoch) of this Calendar undefined. This means that
isSet(field) will return false, and the date and time calculations will treat
the field as if it had never been set."
This is a surprise if you expect the method to zero the field.
--
Lew
Jean-Baptiste Nizet
> 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.
>
Of course it's not returning a singleton, since the javadoc of the
getInstance method explicitely says that "The Calendar returned is
based on the current time [...]".
The calendar object reuses the milliseconds as they were at the time
of the creation, i.e. of your getInstance call. But since you're
calling getInstance twice, you have two different instances of
Calendar, each with different milliseconds.
JB.
Lew
>> I have the feeling that Calendar.getInstance() is not returning a
>> singleton, and that it is also not zeroing out newly-created instances.
Jean-Baptiste Nizet wrote:
> Of course it's not returning a singleton, since the javadoc of the
> getInstance method explicitely says that "The Calendar returned is
> based on the current time [...]".
> The calendar object reuses the milliseconds as they were at the time
> of the creation, i.e. of your getInstance call. But since you're
> calling getInstance twice, you have two different instances of
> Calendar, each with different milliseconds.
Of course Calendar doesn't zero out newly-created instances, since it's
defined to assign the current time to newly-created instances.
--
Lew
ojac...@novator.com
wrote:
#11943: Ah yes, and you are the first person to have noticed this bug
since 1998. Sure.
Eric Sosman
> Harold Yarmouth wrote:
>> 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 ?
Quite obviously not. Not with comprehension, anyhow.
My impression is that he is not looking for help or even
looking for information, but just braying about conclusions
already drawn and unshakeable. There's not much point in
trying to change the mind of someone who's already armored
himself against reality. "The man convinced against his will
is of the same opinion still."
Wojtek
> Wojtek wrote:
>> Arne Vajhøj wrote :
No, I wanted to use the methods in the Date object that the Calendar
object did not have. So the solution was to get a Date object then use
those methods. Seemed obvious to me, yet it did not work.
This was several years ago, so I cannot remember the details, just the
frustration. I think it had something to do with JDBC and a timestamp
column.
BTW, why does a ResultSet not return a Calendar object rather than a
thinly disguised Date object (TimeStamp)? Most of the methods in a Date
object are deprecated. I would be happy to supply a Timezone...
--
Wojtek :-)
Mark Thornton
No it merely indicates a factory pattern. There are numerous cases where
the result is not a singleton.
Lew
> No, I wanted to use the methods in the Date object that the Calendar
> object did not have. So the solution was to get a Date object then use
> those methods. Seemed obvious to me, yet it did not work.
Non-deprecated methods in java.util.Date and their Calendar
counterparts:
Date: Calendar:
after() after()
before() before()
clone() clone()
compareTo() compareTo()
equals() equals()
getTime() getTimeInMillis()
hashCode() hashCode()
setTime() setTimeInMillis()
toString() toString()
--
Lew
Arne Vajhøj
> 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.
That may be the case in the unknown YarmouthLib, but it is most
certainly not the case in the Java library.
Arne
Arne Vajhøj
No. That is something you have misunderstood.
I just grepped the Java API docs. There are nine no-arg getInstance
methods. Of those zero are singletons.
Arne
Arne Vajhøj
> 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?
Considering that the documentation clearly states that it returns
a Calendar instance based on time, then it seems as a very relevant
question.
I see no reason why people should spend time on your perceived
bugs, if you are not even willing to read the documentation
for the classes/methods you think contain a bug.
>> 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.
No. It never means that in the Java API. And I can not think of any
code where you could conclude that.
> . With the semantics of producing a new instance every
> time, there's no apparent reason not to have a public constructor.
Again: read the documentation.
Calendar is an abstract class. You can not instantiate it.
> 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.
Wrong.
In this case it can return different types of calendars.
Yes - different parts of the world use different calendars.
Arne
Arne Vajhøj
Probably true.
Arne
Arne Vajhøj
> BTW, why does a ResultSet not return a Calendar object rather than a
> thinly disguised Date object (TimeStamp)? Most of the methods in a Date
> object are deprecated. I would be happy to supply a Timezone...
In most databases time is just stored as "number of X since Y", so that
Date is a better fit than Calendar.
Arne
Harold Yarmouth
> Whether the "most specific" method should automatically set the
> milliseconds to 0 is subjective.
Perhaps so, but really, it *smells* when one does the
apparently-designers-intended thing to get a Date object accurate to the
second, does so again with the same values, gets Date objects that look
equal when displayed as date strings, and finds that they compare
unequal with .equals.
If this isn't quite a bug, it is a definite wart.
>> 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
An incomplete answer is the "most exact" one? That does not bode well.
Harold Yarmouth
> Harold Yarmouth wrote:
>> 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.
>
> FWIW, many people would consider the Calendar API to be a shining
> example of poor design.
Yes; I'm one of them.
> Like other locale-sensitive classes, Calendar provides a class method,
> getInstance, for getting a generally useful object of this type.
A constructor would have worked as well and potentially caused less
confusion. When the primary use of Calendar is as a date builder,
though, especially useful would be if the most-precise set method 100%
determined the result. When you want the current date, you use new
Date(). When you want a specific date, you use Calendar.getInstance(),
set(), getTime(), and then if you're setting the seconds and higher
units you probably don't want essentially-arbitrary milliseconds. Having
those plays hell with code that constructs accurate-to-the-second dates
and then compares them.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Have you forgotten yet again to check your confrontational attitude at
>> the door?
>
Clearly, the answer to my last question there is "yes" ...
> I see no reason why people should spend time on your ...
Then by all means, go ahead and don't spend any. I'd be glad to be
spared unpleasant and confrontational posts like yours seem prone to being.
> the documentation for the classes/methods you think contain a bug.
If the behavior is (implicitly) documented, but undesirable, then
perhaps it's not technically a bug anymore, but it is still a flaw.
>>> 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.
>
> No.
Yes.
>> . With the semantics of producing a new instance every
>> time, there's no apparent reason not to have a public constructor.
>
> Again: read the documentation.
>
> Calendar is an abstract class. You can not instantiate it.
And this misdesign is somehow my fault? Why not have the default
calendar class be Calendar itself, with overridden behavior as appropriate?
Does anyone ever use any other calendar objects, save by specifying a
locale/timezone?
> > 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.
>
> Wrong.
No, not wrong.
> In this case it can return different types of calendars.
Time zone differences are clearly of the sort of behavioral variations
that are best dealt with by parametrization. Using polymorphism instead
for this is like hitting a fly with a tactical nuclear weapon.
Harold Yarmouth
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> [...]
>>> 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 ?
>
> Quite obviously not.
[rest snipped]
If you have nothing Java-related to say, only personal attacks against a
fellow poster, might I suggest that instead you not say anything at all?
Harold Yarmouth
> Eric Sosman wrote:
>> Arne Vajhøj wrote:
>>> Harold Yarmouth wrote:
>>>> [...]
>>>> 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 ?
>>
>> Quite obviously not.
[rest snipped]
> Probably true.
If you two have nothing Java-related to say, only personal attacks
against a fellow poster, then perhaps you should refrain from saying
anything at all?
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.
>
> Of course it's not returning a singleton, since the javadoc of the
> getInstance method explicitely says that "The Calendar returned is
> based on the current time [...]".
That's ambiguous. Could have meant the current time from the viewpoint
of the guy writing the documentation, so, the time the documentation got
written.
Yes, that would be perverse.
And yes, I've seen worse.
> The calendar object reuses the milliseconds as they were at the time
> of the creation, i.e. of your getInstance call. But since you're
> calling getInstance twice, you have two different instances of
> Calendar, each with different milliseconds.
And therein derives the problematic behavior: using Calendar in the
"natural way" as a date builder results in dates that have an
essentially-random component.
Harold Yarmouth
>> Of course it's not returning a singleton, since the javadoc of the
>> getInstance method explicitely says that "The Calendar returned is
>> based on the current time [...]".
Which could, perversely, be referring to the time the documentation was
being written. Stranger things have happened.
>> The calendar object reuses the milliseconds as they were at the time
>> of the creation, i.e. of your getInstance call. But since you're
>> calling getInstance twice, you have two different instances of
>> Calendar, each with different milliseconds.
>
> Of course Calendar doesn't zero out newly-created instances, since it's
> defined to assign the current time to newly-created instances.
Which is silly, or at least including the milliseconds is silly.
Consider: the main and most "natural" use of Calendar is in
Calendar c = Calendar.getInstance();
c.set(y, mm, d, h, m, s);
Date d = c.getTime();
and this results in a Date with an effectively random set of
milliseconds instead of in a Date wholly determined by y, mm, d, h, m,
and s.
This is, at best, counterintuitive, if not downright broken.
Furthermore, since the current time can be gotten with new Date(), so
you don't need Calendar.getInstance().getTime() to do this, there's
really no reason for Calendar.getInstance() not to zero out *at least*
the milliseconds if not the whole darn thing.
Harold Yarmouth
> #11943: Ah yes, and you are the first person to have noticed this bug
> since 1998.
I made no such claim.
Harold Yarmouth
> Harold Yarmouth wrote:
>> 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).
>
> No
Yes, unless there's an obvious reason for a polymorphic implementation,
such as the method's return value has dynamically variable qualitative
behavior (not just dynamically variable in a parametrizable way).
Harold Yarmouth
> Harold Yarmouth wrote:
>> 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).
>
> No.
Yes, unless there's a clear need for a polymorphic value to be returned,
which would be the case if the value's behavior may vary qualitatively
(so, not just in a parametrizable way).
> That is something you have misunderstood.
That is a gratuitous insult. Please stop posting namecalling and other
personal attacks to this newsgroup and limit your remarks to those about
Java, not those about other people here. Thank you.
> I just grepped the Java API docs. There are nine no-arg getInstance
> methods. Of those zero are singletons.
In the core API, perhaps. If you use lots of libraries and other
third-party code, you'll find rather a different statistical pattern in
that vastly larger code-base.
Harold Yarmouth
> Calendar cal = Calendar.getInstance();
> cal.setTime(.....)
> Calendar cal2 = Calendar.getInstance();
> cal2.setTime(....) // D'oh!
Except that by far the primary usage pattern is
getInstance()
set(...)
Date d1 = getTime();
getInstance()
set(...)
Date d2 = getTime();
etc.
Builder objects that get overwritten with each use aren't considered a
problem, because you usually extract an instance of the immutable output
object type with each use.
I'm thinking that perhaps part of the design problem with Calendar (and
the behavior of clear() mentioned elsewhere seems equally, if not more
problematic) is that it has fuzzily-defined/multiple responsibilities,
perhaps being used as a Date builder and as a mutable Date itself, and
even perhaps for other purposes. Multiple classes with separate,
narrower responsibilities might have been a better design choice.
Harold Yarmouth
>> 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.
>
> That may be the case in the unknown YarmouthLib, but it is most
> certainly not the case in the Java library.
It is the case in a large number of Java libraries, if not in Sun's own
core classes.
Harold Yarmouth
> On Mon, 27 Oct 2008 14:58:30 -0700, "Mike Schilling"
> <mscotts...@hotmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
>> Calendar.getInstance() returns a Calendar representing "now", so each time
>> behavior you're looking for, you need
>>
>> Calendar calendar = Calendar.getInstance();
>> calendar.set(2003,9,10,13,8,42);
>>
>> Yes, this is obnoxious.
>
> This is not a bug because the behaviour is documented and consistent
> with the documentation.
Technically, perhaps. I'd say it's a bug, but the bug is at a higher
abstraction level than "the code doesn't perform to spec in case XYZ".
Instead, the design itself is flawed, i.e. has a bug.
Unfortunately, design issues are subject to more subjectivity than are
code-behavior-vs.-spec issues, which tend to be pretty cut-and-dried.
This could be argued over endlessly, but a statement from elsewhere in
this thread seems apropos:
Joshua Cranmer wrote:
> FWIW, many people would consider the Calendar API to be a shining example of poor design.
My guess is the class was given overloaded responsibilities and ended up
compromising its performance of all of them as a result. In this case,
perhaps its ability to do a good job in its "DateBuilder" role was
compromised by making it conform to some other role.
> I usually call these "gotchas", but I think this sort of thing
> deserves another name, something closer to "design flaw".
Indeed. See above.
Joshua Cranmer
> Joshua Cranmer wrote:
> > Like other locale-sensitive classes, Calendar provides a class method,
> > getInstance, for getting a generally useful object of this type.
>
> A constructor would have worked as well and potentially caused less
> confusion.
Okay, should I be constructing a GregorianCalendar, BuddhistCalendar,
JulianCalendar, what? Constructors aren't polymorphic, Calendars are.
Please note that the semantics are defined in the documentation.
Let me repeat: they're DOCUMENTED. This isn't something that's buried in
paragraph 9 of the 30th page, it's mentioned in paragraph 3 of the class
documentation at about the position my eyes naturally gravitate towards.
Also, this is not a notation unique to the Calendar class; a subset of
classes in Java also use similar semantics for getInstance.
I haven't checked the tutorials, but it's probably discussed there as well.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Lew
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>> > Like other locale-sensitive classes, Calendar provides a class method,
>> > getInstance, for getting a generally useful object of this type.
>>
>> A constructor would have worked as well and potentially caused less
>> confusion.
>
> Okay, should I be constructing a GregorianCalendar, BuddhistCalendar,
> JulianCalendar, what? Constructors aren't polymorphic, Calendars are.
>
> Please note that the semantics are defined in the documentation.
>
> Let me repeat: they're DOCUMENTED. This isn't something that's buried in
> paragraph 9 of the 30th page, it's mentioned in paragraph 3 of the class
> documentation at about the position my eyes naturally gravitate towards.
>
> Also, this is not a notation unique to the Calendar class; a subset of
> classes in Java also use similar semantics for getInstance.
>
> I haven't checked the tutorials, but it's probably discussed there as well.
Furthermore, for anyone who has read /Effective Java/ by Joshua Bloch, or the
excerpt in
<http://www.ddj.com/java/208403883>
or otherwise studied best practices for Java programming, it is well known
that factories are often preferable to constructors, in part for the reasons
Joshua mentions.
Note from the article:
> # getInstance -- Returns an instance that is described by the parameters
> but cannot be said to have the same value. In the case of a singleton,
> getInstance takes no parameters and returns the sole instance.
>
> # newInstance -- Like getInstance, except that newInstance guarantees
> that each instance returned is distinct from all others.
See? No guarantee or convention that 'getInstance' return a singleton. Only
one "in the case of a singleton".
--
Lew
Eric Sosman
> Joshua Cranmer wrote:
> A constructor would have worked as well and potentially caused less
> confusion.
A constructor cannot make a run-time decision about the
class of the object it builds.
Mike Schilling
> Note from the article:
>> # getInstance -- Returns an instance that is described by the
>> parameters but cannot be said to have the same value. In the case
>> of
>> a singleton, getInstance takes no parameters and returns the sole
>> instance. # newInstance -- Like getInstance, except that
>> newInstance guarantees
>> that each instance returned is distinct from all others.
>
> See? No guarantee or convention that 'getInstance' return a
> singleton. Only one "in the case of a singleton".
But this does argue that Calendar.newInstance() would be more logical,
since all Calendars returned are unique.
Arne Vajhøj
Yes.
But apparently SUN does not seem to think so. There are lots of
getInstance methods that return non singleton. I counted 44 classes
in the Java API.
Arne
Arne Vajhøj
> Jean-Baptiste Nizet wrote:
>>> I have the feeling that Calendar.getInstance() is not returning a
>>> singleton, and that it is also not zeroing out newly-created instances.
>>
>> Of course it's not returning a singleton, since the javadoc of the
>> getInstance method explicitely says that "The Calendar returned is
>> based on the current time [...]".
>
> That's ambiguous. Could have meant the current time from the viewpoint
> of the guy writing the documentation, so, the time the documentation got
> written.
I hereby nominate that argument for the title as the most lame
argument posted to cljp in 2008.
>> The calendar object reuses the milliseconds as they were at the time
>> of the creation, i.e. of your getInstance call. But since you're
>> calling getInstance twice, you have two different instances of
>> Calendar, each with different milliseconds.
>
> And therein derives the problematic behavior: using Calendar in the
> "natural way" as a date builder results in dates that have an
> essentially-random component.
Well - everyone else seems perfectly capable of reading the docs
and use the Calendar class.
Arne
Arne Vajhøj
> Joshua Cranmer wrote:
> > getInstance, for getting a generally useful object of this type.
>
> A constructor would have worked as well and potentially caused less
> confusion.
I repeat: you can not instantiate an abstract class.
> When the primary use of Calendar is as a date builder,
But it is not. Its primary use are to get local specific interpretation
and modifications of date objects.
> though, especially useful would be if the most-precise set method 100%
> determined the result. When you want the current date, you use new
> Date(). When you want a specific date, you use Calendar.getInstance(),
> set(), getTime(), and then if you're setting the seconds and higher
> units you probably don't want essentially-arbitrary milliseconds.
No. Everyone that read the documentation will of course set those
as well (if needed in the context).
Arne
Arne Vajhøj
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Have you forgotten yet again to check your confrontational attitude
>>> at the door?
>>
>> a Calendar instance based on time, then it seems as a very relevant
>> question.
>
No I am trying to bring you from non-programmer to programmer-newbee
by telling you to read the documentation instead of posting silly
bug posts to usenet.
>> I see no reason why people should spend time on your perceived
>> bugs, if you are not even willing to read the documentation
>> for the classes/methods you think contain a bug.
>
> Then by all means, go ahead and don't spend any.
The readers would prefer that you stopped posting bogus bug reports.
>>>> 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.
>>
>> No. It never means that in the Java API. And I can not think of any
>> code where you could conclude that.
> Yes.
Please tell me where in the Java API you see that practice ?
Or any other Java API.
>>> . With the semantics of producing a new instance every
>>> time, there's no apparent reason not to have a public constructor.
>>
>> Again: read the documentation.
>>
>> Calendar is an abstract class. You can not instantiate it.
>
> And this misdesign is somehow my fault? Why not have the default
> calendar class be Calendar itself, with overridden behavior as appropriate?
Because it would be very bad OO design.
You do not let Calendar be GregorianCalendar and then ask all
other Calendars to overwrite most methods.
Read up on "is a" principle.
>> In this case it can return different types of calendars.
>
> Time zone differences are clearly of the sort of behavioral variations
> that are best dealt with by parametrization. Using polymorphism instead
> for this is like hitting a fly with a tactical nuclear weapon.
No. Polymorphism is the correct OO solution to this. The other approach
will result in a ton of if statements and switches in the methods.
Arne
Arne Vajhøj
> Lew wrote:
>>> Of course it's not returning a singleton, since the javadoc of the
>>> getInstance method explicitely says that "The Calendar returned is
>>> based on the current time [...]".
>
> Which could, perversely, be referring to the time the documentation was
> being written. Stranger things have happened.
You will not get nominated twice !
>>> The calendar object reuses the milliseconds as they were at the time
>>> of the creation, i.e. of your getInstance call. But since you're
>>> calling getInstance twice, you have two different instances of
>>> Calendar, each with different milliseconds.
>>
>> Of course Calendar doesn't zero out newly-created instances, since
>> it's defined to assign the current time to newly-created instances.
>
> Which is silly, or at least including the milliseconds is silly.
Since it stores time in milliseconds and need to convert to and
from Date with milliseconds then avoiding using milliseconds
would be difficult and inconsistent.
Arne
Arne Vajhøj
There are.
Arab, Chines and Japanese calendars are very different from Gregorian
and Julian calendars.
Arne
Arne Vajhøj
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> 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).
>> I just grepped the Java API docs. There are nine no-arg getInstance
>> methods. Of those zero are singletons.
>
> In the core API, perhaps. If you use lots of libraries and other
> third-party code, you'll find rather a different statistical pattern in
> that vastly larger code-base.
Please provide a reference to which.
Arne
Arne Vajhøj
Just name 10 libraries.
Arne
Arne Vajhøj
> Mike Schilling wrote:
>> Calendar cal = Calendar.getInstance();
>> cal.setTime(.....)
>> Calendar cal2 = Calendar.getInstance();
>> cal2.setTime(....) // D'oh!
>
> Except that by far the primary usage pattern is
>
> getInstance()
> set(...)
> Date d1 = getTime();
> getInstance()
> set(...)
> Date d2 = getTime();
> etc.
I don't think so. That i a rather rare usage of Calendar.
And note that even that usage is working fine, if the programmer
reads the docs.
Arne
Harold Yarmouth
> Harold Yarmouth wrote:
>> Lew wrote:
>>>> Of course it's not returning a singleton, since the javadoc of the
>>>> getInstance method explicitely says that "The Calendar returned is
>>>> based on the current time [...]".
>>
>> Which could, perversely, be referring to the time the documentation
>> was being written. Stranger things have happened.
>
> You will not get nominated twice !
Excuse me?
>>> Of course Calendar doesn't zero out newly-created instances, since
>>> it's defined to assign the current time to newly-created instances.
>>
>> Which is silly, or at least including the milliseconds is silly.
>
> Since it stores time in milliseconds and need to convert to and
> from Date with milliseconds then avoiding using milliseconds
> would be difficult and inconsistent.
That's begging the question. You can't claim that including the
milliseconds isn't silly because it includes the milliseconds. Not with
a straight face, surely.
As I said previously, it could feed zero milliseconds to Date. Or have
its own milliseconds, but zero them out if you set everything that's
coarser-grained.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Jean-Baptiste Nizet wrote:
>>>> I have the feeling that Calendar.getInstance() is not returning a
>>>> singleton, and that it is also not zeroing out newly-created instances.
>>>
>>> Of course it's not returning a singleton, since the javadoc of the
>>> getInstance method explicitely says that "The Calendar returned is
>>> based on the current time [...]".
>>
>> That's ambiguous. Could have meant the current time from the viewpoint
>> of the guy writing the documentation, so, the time the documentation
>> got written.
>
> I hereby nominate that argument for the title as the most lame
> argument posted to cljp in 2008.
I hereby nominate you for the title of the rudest poster in cljp.
If you can't keep things professional instead of getting personal, it
may be time for you to hang up your modem and go on vacation for, oh,
say, a thousand years or so.
>> And therein derives the problematic behavior: using Calendar in the
>> "natural way" as a date builder results in dates that have an
>> essentially-random component.
(And Arne has nothing constructive to say here, either, just more
personal attacks.)
Harold Yarmouth
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> Harold Yarmouth wrote:
> >>>> Have you read the documentation ?
>>>> Have you forgotten yet again to check your confrontational attitude
>>>> at the door?
>>>
>>> Considering that the documentation clearly states that it returns
>>> a Calendar instance based on time, then it seems as a very relevant
>>> question.
>>
>> Clearly, the answer to my last question there is "yes" ...
>
> No
Yes, it is.
> I am trying to bring you from non-programmer to programmer-newbee
I am an experienced programmer and I'll thank you to stop badmouthing me
in public!
>>> I see no reason why people should spend time on your perceived
>>> bugs, if you are not even willing to read the documentation
>>> for the classes/methods you think contain a bug.
>>
>> Then by all means, go ahead and don't spend any.
>
> The readers would prefer
The readers can make up their own individual minds without any arrogant
presumption by you.
If you consider my posts a waste of time, DON'T READ THEM. Filter my
posts, or just plain ignore them. Don't reply to every one of them to
publicly tell lies about me or otherwise waste everyone ELSE's time.
>>>> It usually implies something of the sort, if it takes no arguments
>>>> and there's no public constructor.
>>>
>>> And I can not think of any code where you could conclude that.
>> Yes.
>
> Please tell me where in the Java API you see that practice ?
I didn't say in the Java API, I just said "any code". Or rather, *you* did.
>> And this misdesign is somehow my fault? Why not have the default
>> calendar class be Calendar itself, with overridden behavior as
>> appropriate?
>
> Because it would be very bad OO design.
No, it wouldn't.
> You do not let Calendar be GregorianCalendar and then ask all
> other Calendars to overwrite most methods.
Who said anything about that?
> Read up on
Stop being rude and condescending. Do not bark orders at me. Or I will
do the same to you. Got it?
>> Time zone differences are clearly of the sort of behavioral variations
>> that are best dealt with by parametrization. Using polymorphism
>> instead for this is like hitting a fly with a tactical nuclear weapon.
>
> No.
Yes.
> The other approach will result in a ton of if statements and switches
> in the methods.
Nonsense. It will result in some pluses and minuses of the timezone
offset here and there, that's all.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>> > Like other locale-sensitive classes, Calendar provides a class method,
>> > getInstance, for getting a generally useful object of this type.
>>
>> A constructor would have worked as well and potentially caused less
>> confusion.
>
> Okay, should I be constructing a GregorianCalendar, BuddhistCalendar,
> JulianCalendar, what? Constructors aren't polymorphic, Calendars are.
This is ludicrous. Only one of the above is in common use for business
purposes. The others are essentially fluff and shouldn't complicate the
core APIs used for getting actual serious work done.
> Let me repeat: they're DOCUMENTED.
Let ME repeat: Just because something is documented does not make its
design automatically be without flaws.
> This isn't something that's buried in
> paragraph 9 of the 30th page, it's mentioned in paragraph 3 of the class
> documentation at about the position my eyes naturally gravitate towards.
My IDE shows me the documentation for the method whose invocation I'm
writing. That would be the set method in this case.
Why is this argument getting so long and repetitive, anyway? You have
said your opinions and I have said mine. There's no point in your
repeating the same set of opinions a second time.
Harold Yarmouth
> Joshua Cranmer wrote:
>> Okay, should I be constructing a GregorianCalendar, BuddhistCalendar,
>> JulianCalendar, what? Constructors aren't polymorphic, Calendars are.
The answer, 99.99999% of the time, is going to be one particular one of
these.
>> Let me repeat: they're DOCUMENTED.
Let ME repeat: Just because something is documented does not
automatically absolve it of a charge of having a flawed DESIGN.
>> This isn't something that's buried
>> in paragraph 9 of the 30th page, it's mentioned in paragraph 3 of the
>> class documentation at about the position my eyes naturally gravitate
>> towards.
And the IDEs tend to show the current method documentation (say, for
"set") only.
> Furthermore, for anyone who has read /Effective Java/ by Joshua Bloch
Not relevant, since not everyone HAS read that or any other book.
> it is well known that factories are often preferable to constructors,
> in part for the reasons Joshua mentions.
I don't see any more need for a factory of date builders than I do for a
factory of StringBuilders. StringBuilder gets by with a straight
constructor.
See my other post about suspecting that they mixed multiple
responsibilities into one class, ending up with a boondoggle for their
efforts.
>> # newInstance -- Like getInstance, except that newInstance guarantees
>> that each instance returned is distinct from all others.
This might have been a more appropriate method name, given the present
implementation of the class.
> See? No guarantee or convention that 'getInstance' return a singleton.
I never claimed otherwise. I said that in the absence of a strong reason
for the return value to be polymorphic, it tends to indicate a singleton
or otherwise a "bound" instance of some sort.
Harold Yarmouth
But I never said that getInstance methods return only singletons! I said
that no-argument getInstance methods with no obvious reason to return
polymorphic values tend to indicate a singleton or some other "bound
instance", for example a per-thread instance.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>> > Like other locale-sensitive classes, Calendar provides a class method,
>> > getInstance, for getting a generally useful object of this type.
>>
>> A constructor would have worked as well and potentially caused less
>> confusion.
>
> I repeat: you can not instantiate an abstract class.
And I repeat: it should be concrete. We don't have an abstract
StringBuilder and a bunch of polymorphic StringBuilder subclasses, even
though string encodings and characters and presentation are often
heavily locale-dependent, so why an abstract and polymorphic date
builder type?
The only explanation I can think of, besides sheer perversity, is
because they gave one class multiple responsibilities.
>> When the primary use of Calendar is as a date builder,
>
> But it is not.
Sure it is.
> Its primary use are to get local specific interpretation and
> modifications of date objects.
You can get that by adding the time zone offset to the time, for
Chrissake, and using a suitable DateFormat when converting to and from
user-visible or -supplied strings.
>> though, especially useful would be if the most-precise set method 100%
>> determined the result. When you want the current date, you use new
>> Date(). When you want a specific date, you use Calendar.getInstance(),
>> set(), getTime(), and then if you're setting the seconds and higher
>> units you probably don't want essentially-arbitrary milliseconds.
>
> No. Everyone that read the documentation will of course set those
> as well (if needed in the context).
Except that the set method doesn't let you. It only has the six
arguments years, months, days, hours, minutes, and seconds. So the natural
Calendar c = Calendar.getInstance();
c.set(yy,mm,dd,h,m,s);
Date d = c.getTime();
results in a date with a seemingly-random component when really the
above should suffice to yield a Date object dependent solely upon yy,
mm, dd, h, m, and s. Instead, to get such a Date object apparently
requires extra effort of some kind.
And that, by itself, is sufficient to demonstrate conclusively that a
design flaw exists.
So your continuing to argue with me (and even to get quite hostile!)
regarding whether or not such a flaw exists is pointless and stupid. It
exists. It is as plain as the nose on your face. I don't know why you
continue to deny it. A misguided knee-jerk impulse to defend Java
whenever it is criticized, however constructively?
I don't know and I don't really care, either. Please stop repeating
yourself, please stop attacking other people and not merely
dispassionately discussing Java, and please stop cluttering up this
thread and this newsgroup with pointless bickering.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Mark Thornton wrote:
>>> Harold Yarmouth wrote:
>>>> 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).
>>>
>>> No
>>
>> Yes, unless there's an obvious reason for a polymorphic
>> implementation, such as the method's return value has dynamically
>> variable qualitative behavior (not just dynamically variable in a
>> parametrizable way).
>
> There are.
No, there aren't.
> Arab, Chines and Japanese calendars are very different from Gregorian
> and Julian calendars.
Irrelevant. Nobody much uses pre-industrial calendars anymore, certainly
not for business applications and e-commerce.
Harold Yarmouth
I can't. It's just the code that's out there. You get a feel for these
things working with, seeing, using, and writing large amounts of code.
So you will have your answer if and when you are sufficiently
experienced. If you don't have it yet, just keep working with Java and
the patterns will become apparent to you in the fullness of time.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Mike Schilling wrote:
>>> Calendar cal = Calendar.getInstance();
>>> cal.setTime(.....)
>>> Calendar cal2 = Calendar.getInstance();
>>> cal2.setTime(....) // D'oh!
>>
>> Except that by far the primary usage pattern is
>>
>> getInstance()
>> set(...)
>> Date d1 = getTime();
>> getInstance()
>> set(...)
>> Date d2 = getTime();
>> etc.
>
> I don't think so. That i a rather rare usage of Calendar.
No, it is the single most common usage of Calendar.
> And note that even that usage is working fine
No, it is not. It violates the principle of least astonishment. (And no,
documenting surprising behavior does not negate its qualifying as
surprising, else the principle would become meaningless since then any
coder could trivially avoid violating it.)
Harold Yarmouth
>> It is the case in a large number of Java libraries, if not in Sun's
>> own core classes.
>
> Just name 10 libraries.
Just you stop pestering me and, especially, insinuating in public that
I'm some sort of liar or charlatan. It is exceptionally rude and
uncalled-for behavior that I shall not tolerate from you or anybody else!
(If you insist -- almost ANY ten.)
Joshua Cranmer
And since when is Java only for business applications? Nice to know that
you're so culturally sensitive in ignoring such major calendars as the
Chinese calendar, Arabic calendar, and Hebrew calendar.
Lew
Harold Yarmouth wrote:
>>> In the core API, perhaps. If you use lots of libraries and other
>>> third-party code, you'll find rather a different statistical pattern
>>> in that vastly larger code-base.
Arne Vajhøj wrote:
>> Please provide a reference to which.
Harold Yarmouth wrote:
> I can't. It's just the code that's out there. You get a feel for these
> things working with, seeing, using, and writing large amounts of code.
> So you will have your answer if and when you are sufficiently
> experienced. If you don't have it yet, just keep working with Java and
> the patterns will become apparent to you in the fullness of time.
This is what happens when you accidentally delete your kill file. You find a
complete redefinition of statistical analysis.
Statistics by definition involves objectivity and measurement. A "feel for
these things" is notoriously inaccurate. It's based on a non-random sample
and subject to subjectivity. The assertion requires evidence. Absent
evidence, we could debate both sides until the cows come home and never arrive
at truth.
I have ten years' Java experience and my "feel for these things" is quite
different. It also helps that I have authoritative evidence that 'getX'
factories don't necessarily imply singletons, /op. cit./.
<http://www.ddj.com/java/208403883>
When the gods speak, mortals should listen.
--
Lew
Lew
>> Furthermore, for anyone who has read /Effective Java/ by Joshua Bloch
Harold Yarmouth wrote:
> Not relevant, since not everyone HAS read that or any other book.
You had better.
How can anyone claim to be any good at any programming without reading any book?
Rhetorical question, don't bother answering. Kill file re-established.
--
Lew
Joshua Cranmer
> Lew wrote:
>
> Not relevant, since not everyone HAS read that or any other book.
It is relevant, since it is one of the best references for good Java
design. Heck, I haven't read it myself yet, but I still know many of the
most useful facts in there. Like this one, for example.
>>> # newInstance -- Like getInstance, except that newInstance guarantees
>>> that each instance returned is distinct from all others.
>
> This might have been a more appropriate method name, given the present
> implementation of the class.
This method name is internally consistent within Java's core APIs, in
particular locale-related APIs.
> I never claimed otherwise. I said that in the absence of a strong reason
> for the return value to be polymorphic, it tends to indicate a singleton
> or otherwise a "bound" instance of some sort.
The Calendar class is obviously polymorphic from its API; this fact you
cannot deny, independent of whether or not it /should/ be. Since it /is/
polymorphic, that means that getInstance does not have to abide by a
general implied contract for non-polymorphic classes.
Joshua Cranmer
> Arne Vajhøj wrote:
>> I am trying to bring you from non-programmer to programmer-newbee
>
> I am an experienced programmer and I'll thank you to stop badmouthing me
> in public!
For an experienced programmer, you seem strangely unwilling to read the
documentation in question.
Lew
>> I am trying to bring you from non-programmer to programmer-newbee
Harold Yarmouth wrote:
> I am an experienced programmer and I'll thank you to stop badmouthing me
> in public!
Ancient Japanese saying: Only perfect practice makes perfect.
Ancd you aren't going to thank him for anything.
--
Lew
John W Kennedy
Well, I tried to give you the benefit of the doubt about being an
asshole, but you had to raise the ante by being an ignorant racist, too.
*PLONK*
--
John W. Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"
Daniel Pitts
Bad design -> bug
Just because it is designed poorly, doesn't mean there is a bug. Poor
design might lead to a bug (as it did in your case), but a bug is
formally "not working to specification". Calendar works to its flawed
specification.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Lew
> Just because it is designed poorly, doesn't mean there is a bug. Poor
> design might lead to a bug (as it did in your case), but a bug is
> formally "not working to specification". Calendar works to its flawed
> specification.
Is it flawed? Is it really?
--
Lew
Mike Schilling
The fact that to fully initialize a Calendar to a known time, you need to
1. Call the getInstance method, which lets you specify all but one of its
parameters, and then
2. Call a set method, to set the parameter that couldn't be specified in
step 1, and was instead set to a useless, not even consistent value by step
1
is a flaw.
Arne Vajhøj
Calendar and Date are not very elegant created.
I do not see Paulmouth's problem as a problem though.
Arne
Arne Vajhøj
GetInstance does not let you set any of the "virtual fields" (in lack
of better word to describe the y m d h m s ms that I am sure are not
stored as such).
It has a set method that can set each of them individually and
are what should have been used by Paulmouth.
And then it have some convenience methods that set:
y m d
y m d h m
y m d h m s
And I agree that there should also be one for:
y m d h m s ms
But that is a minor flaw.
Arne
Martien Verbruggen
I think that it could use a set method that allows one to fully
specify its internal state. All that's needed for that is the addition
of a set method with one extra int argument.
To call it flawed for this reason is maybe a bit strong.
Martien
--
|
Martien Verbruggen | Since light travels faster than sound, is
| that why some people appear bright until you
| hear them speak?
Lew
I tend to agree about Date. Calendar is a bit klunky, perhaps innately due to
the irrational psychosocial nature of human calendars, and its 'clear()'
method is truly confusing. So I agree that it has flaws, but the blanket
condemnation of Calendar as "flawed" implies that it is far less useful than
it really is.
I'm currently shin-deep in Calendar code for a project, so I'm seeing both
sides of it, the useful and the flawed.
--
Lew
Joshua Cranmer
FWIW, this (and half the discussion on Calendar, etc.) is a rather moot
point thanks to this feature which should be in Java 7:
<https://jsr-310.dev.java.net/>
Eric Sosman
>
> I tend to agree about Date. Calendar is a bit klunky, perhaps innately
> due to the irrational psychosocial nature of human calendars, and its
> 'clear()' method is truly confusing. So I agree that it has flaws, but
> the blanket condemnation of Calendar as "flawed" implies that it is far
> less useful than it really is.
Here are two things I've observed:
1) Every date/time package I've ever run across in any
programming language has been deficient in one way or another,
sometimes to the point of looking utterly stupid, and
2) Many of those date/time packages were designed and
implemented by people a whole lot smarter than I am.
From these observations, I draw two conclusions:
A) The ways people reckon dates and times are far more
complicated than a naive glance suggests, and
B) It's folly to throw words like "stupid" around. (Or
stupid to throw words like "folly" around; I can never keep
that straight.)
As examples of (A), consider "same time next month" when
uttered on January 30, or "same time next year" when uttered
on February 29. Even "same time tomorrow" will be tricky in
my locale for most of this Saturday.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Arne Vajhøj
"For every complex problem, there is a solution that is simple, neat,
and wrong."
:-)
Arne
Owen Jacobson
> Lew wrote:
>
> > I tend to agree about Date. Calendar is a bit klunky, perhaps innately
> > due to the irrational psychosocial nature of human calendars, and its
> > 'clear()' method is truly confusing. So I agree that it has flaws, but
> > the blanket condemnation of Calendar as "flawed" implies that it is far
> > less useful than it really is.
>
> Here are two things I've observed:
>
> 1) Every date/time package I've ever run across in any
> programming language has been deficient in one way or another,
> sometimes to the point of looking utterly stupid, and
Have you looked at PostgreSQL's implementation of INTERVAL, TIMESTAMP,
and DATETIME types? It's about on par with Joda for "least-ass time
API": it gets timezones right, has a fairly complete arithmetic model
based on points in time and un-anchored intervals ("1 month" is an
interval), and it's high resolution (seconds to six decimal places).
It also uses a fairly natural convention for arithmetic: intervals
whose units are seconds are exact, and intervals whose units are
conventional clock or calendar periods like hours or months are
context-dependent. Thus, 'now + 1 month' is the last day of November
(since today is the last day of October), but 'now + 31 days' is
December 1st, and 'now + 2646025 seconds' is also December 1st.
Lew
> Have you looked at PostgreSQL's implementation of INTERVAL, TIMESTAMP,
> and DATETIME types? It's about on par with Joda for "least-ass time
There isn't any such Postgres type as "DATETIME".
<http://www.postgresql.org/docs/8.3/interactive/datatype-
datetime.html>
There's DATE and there's TIME.
> API": it gets timezones right, has a fairly complete arithmetic model
> based on points in time and un-anchored intervals ("1 month" is an
> interval), and it's high resolution (seconds to six decimal places).
> It also uses a fairly natural convention for arithmetic: intervals
> whose units are seconds are exact, and intervals whose units are
> conventional clock or calendar periods like hours or months are
> context-dependent. Thus, 'now + 1 month' is the last day of November
> (since today is the last day of October), but 'now + 31 days' is
> December 1st, and 'now + 2646025 seconds' is also December 1st.
Postgres follows the SQL standard wrt to datetime types. Probably the
least compliant RDBMS in this area is Access, followed by MySQL.
MySQL particularly has an idiosyncratic semantic for TIMESTAMP.
--
Lew
Eric Sosman
> On Oct 30, 11:00 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> Lew wrote:
>>
>>> I tend to agree about Date. Calendar is a bit klunky, perhaps innately
>>> due to the irrational psychosocial nature of human calendars, and its
>>> 'clear()' method is truly confusing. So I agree that it has flaws, but
>>> the blanket condemnation of Calendar as "flawed" implies that it is far
>>> less useful than it really is.
>> Here are two things I've observed:
>>
>> 1) Every date/time package I've ever run across in any
>> programming language has been deficient in one way or another,
>> sometimes to the point of looking utterly stupid, and
>
> Have you looked at PostgreSQL's implementation of INTERVAL, TIMESTAMP,
> and DATETIME types?
No. I've only looked at FORTRAN, Telcomp, BASIC, Algol,
SNOBOL, XPL, PL/I, MarkIV, TAL, C, Pascal, Common LISP, Java,
several assemblers, and assorted scripting languages. (And
I once debugged a COBOL program despite not knowing the
language.) A negligible sample of the programming languages
available, to be sure.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Harold Yarmouth
>>
> Harold Yarmouth wrote:
>>>> In the core API, perhaps. If you use lots of libraries and other
>>>> third-party code, you'll find rather a different statistical pattern
>>>> in that vastly larger code-base.
>
> Arne Vajhøj wrote:
>>> Please provide a reference to which.
>
> Harold Yarmouth wrote:
>> I can't. It's just the code that's out there. You get a feel for these
>> things working with, seeing, using, and writing large amounts of code.
>> So you will have your answer if and when you are sufficiently
>> experienced. If you don't have it yet, just keep working with Java and
>> the patterns will become apparent to you in the fullness of time.
>
> more vaguely-insulting verbiage in this veil trimmed]
I thought this was a Java newsgroup, not a
Lew's-personal-opinions-of-Harold-Yarmouth one.
> Absent evidence, we could debate both sides until the cows come home and
> never arrive at truth.
That would be far preferable to the mudslinging presently being
observed, in my opinion.
> I have authoritative evidence that 'getX' factories don't necessarily
> imply singletons
I never claimed otherwise. I said no-argument getInstance methods in the
absence of a clear need for a polymorphic return value, which is a far
narrower and more specific set of circumstances.
> When the gods speak, mortals should listen.
When arrogant and megalomaniacal twits more or less come right out and
call themselves "gods" in a bid to be heard, mortals should consign them
to the depths of their killfiles.
Ergo, plonk.
Harold Yarmouth
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> Arab, Chines and Japanese calendars are very different from Gregorian
>>> and Julian calendars.
>>
>> Irrelevant. Nobody much uses pre-industrial calendars anymore,
>> certainly not for business applications and e-commerce.
>
> And since when is Java only for business applications?
Since never, but it is predominantly used for business applications at
this time.
> Nice to know that you're so culturally sensitive in ignoring
"Cultural sensitivity" is neither here nor there. "Cultural sensitivity"
is not a major concern of programming language or API design. It may be
a concern of application user-interface design, but that's a whole
different kettle of fish.
Imagine if it were otherwise -- Calendar would not accept dates before
4004 BC, to avoid offending Christians, or after 2012, to avoid
offending Mayans. There'd be something to prevent the coding of genetic
algorithms. SecureRandom and all of the crypto would be missing, since
some cultures strongly frown upon any kind of concealment or disguise of
information, either from people in general or specifically from
government or religious authority. Programs written in Java would refuse
to work on Sundays. The sound, MIDI, and MP3 libraries would refuse to
work when the current locale setting was Afghanistan and the system
clock set prior to around mid-2003. And so forth.
That is the sort of mess we'd have if we took
designing-in-cultural-sensitivity to its logical conclusion.
The API and language should provide the application designer with the
tools to a) write the internal business logic to use standard,
internationalized units and b) localize the user interface.
Which means using the plain-Jane Gregorian calendar under the hood in
Date and other business objects related to dates, with DateFormat or
other similar classes providing translations into locale-specific
representations.
Harold Yarmouth
> Well, I tried to give you the benefit of the doubt about being an
> asshole, but you had to raise the ante by being an ignorant racist, too.
Do not lie about me in public again. I am not either an asshole or an
ignorant racist.
You, on the other hand, appear to be at least the former of those two.
It is certainly not racist to make an observation about what is standard
practice in commerce, as you seemed to be implying. It is merely making
an observation.
People are free to use their older calendars to schedule religious
ceremonies or whatever. However, such things have no place in core
utility classes in a programming language API; they belong in
localization code affecting input parsing and output display, i.e. in UI
code, rather than the code for business-layer objects, where they belong
in the standard API at all rather than in third-party libraries.
That is not a racist remark either. It is merely an observation of fact.
Localization belongs in the UI layer, not in the business layer. The
alternative is catastrophic: applications that communicate with each
other won't be speaking the same language.
It's no more racist to say "localization belongs in the UI layer" than
it is "insensitive to someone's time zone" to say that the internal,
file, and network representations of times should be in GMT with time
zones dealt with in the UI layer.
It is merely logical.
Harold Yarmouth
>> Not relevant, since not everyone HAS read that or any other book.
>
> You had better.
I'm easy to get along with most of the time, Lew, but I don't like
bullies, I don't like threats, and I don't like you.
Please go away.
> How can anyone claim to be any good at any programming without reading
> any book?
Experience, rather than book reading, is the predominant influence on
programming skill. Study after study has shown this.
Arne Vajhøj
> Arne Vajhøj wrote:
>>> Lew wrote:
>>>>> getInstance method explicitely says that "The Calendar returned is
>>>>> based on the current time [...]".
>>>
>>> Which could, perversely, be referring to the time the documentation
>>> was being written. Stranger things have happened.
>>
>> You will not get nominated twice !
>
> Excuse me?
For "the most lame argument posted to cljp in 2008".
Arne
Harold Yarmouth
> Harold Yarmouth wrote:
>> Lew wrote:
>>> Furthermore, for anyone who has read /Effective Java/ by Joshua Bloch
>>
>> Not relevant, since not everyone HAS read that or any other book.
>
> It is relevant
No, it is not, as I have already explained.
> it is one of the best references for good Java design.
But not the only, nor the most accessible (not in a reading-difficulty
sense, but in a
minimum-effort-and-expense-to-get-a-copy-in-front-of-your-eyeballs
sense). So it is not sensible to presume that everyone has read it, and
it is furthermore ARROGANT and presumptuous to assert that everyone MUST
read it. Unless you sit on the board of some certification body with the
authority to actually pass down such a commandment and back it up with
force of some sort. (In that case, it would merely be foolish.)
> Heck, I haven't read it myself yet
Ouch. I'd forgotten I'd set my hypocrisy alarm to the highest gain. Now
my ears are gonna be ringing all goddamn week.
>>>> # newInstance -- Like getInstance, except that newInstance
>>>> guarantees that each instance returned is distinct from all others.
>>
>> This might have been a more appropriate method name, given the present
>> implementation of the class.
>
> This method name is internally consistent within Java's core APIs, in
> particular locale-related APIs.
Locale-related APIs belong in the UI-layer classes, not in the core
business classes (including Date and the class used as a date builder).
Calendar seems to have split responsibilities -- poor OO design.
>> I never claimed otherwise. I said that in the absence of a strong
>> reason for the return value to be polymorphic
>
> The Calendar class is obviously polymorphic
I didn't say anything about whether or not something IS, I said
something about whether or not there is a strong reason for it to BE.
The two are not identical.
Arne Vajhøj
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Lew wrote:
>>>> it's defined to assign the current time to newly-created instances.
>>>
>>> Which is silly, or at least including the milliseconds is silly.
>>
>> Since it stores time in milliseconds and need to convert to and
>> from Date with milliseconds then avoiding using milliseconds
>> would be difficult and inconsistent.
>
> That's begging the question. You can't claim that including the
> milliseconds isn't silly because it includes the milliseconds. Not with
> a straight face, surely.
It has to include the milliseconds because it has to convert
to and from Date which contains milliseconds.
Arne