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



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


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

1065805722140
1065805722828

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


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

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

The JDK documentation says this:

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

So the behaviour you have noted is by design.

Mark Thornton

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

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

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

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

Nope.

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

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

So, this still looks like a bug to me.

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Stanimir

Stanimir Stamenkov wrote:

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


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

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

Yep.

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

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

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

Yes, this is obnoxious. 

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

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

Mark Thornton

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

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

Arne

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 :-)

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

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

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 :-)

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? 

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.

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).

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.

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.

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

Harold Yarmouth wrote:
> 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.)

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. 

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.

> 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

On Mon, 27 Oct 2008 14:58:30 -0700, "Mike Schilling"
<mscottschilling@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.

Stanimir Stamenkov wrote:
> 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

On 27 oct, 22:26, Harold Yarmouth <hyarmouth991...@hotmail.com> 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.
>

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.

"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.

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

On Oct 27, 5:26=A0pm, Harold Yarmouth <hyarmouth991...@hotmail.com>
wrote:
> Stanimir Stamenkov wrote:
> > Mon, 27 Oct 2008 16:42:21 -0400, /Harold Yarmouth/:
>
> >> Calendar calendar =3D Calendar.getInstance();
> >> calendar.set(2003,9,10,13,8,42);
> >> Date date =3D 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?)

#11943: Ah yes, and you are the first person to have noticed this bug
since 1998.  Sure.

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.  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."

-- 
Eric.Sosman@sun.com

Mike Schilling wrote :
> 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?

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 :-)

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 it merely indicates a factory pattern. There are numerous cases where 
the result is not a singleton.

Wojtek 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.

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

Harold Yarmouth wrote:
> 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

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

Harold Yarmouth wrote:
> 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

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.  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."

Probably true.

Arne

Wojtek wrote:
> 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

Stanimir Stamenkov wrote:
> 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.

Joshua Cranmer wrote:
 > 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.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Have you forgotten yet again to check your confrontational attitude at 
>> the door?
> 
> Considering that the documentation clearly states ...

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.

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]

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?

Arne Vajh�j wrote:
> 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?

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.

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.

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.

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

ojacobson@novator.com wrote:
> #11943: Ah yes, and you are the first person to have noticed this bug
> since 1998.

I made no such claim.

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).

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).
> 
> 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.

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.

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.

Arne Vajh�j wrote:
>> 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.

Roedy Green wrote:
> On Mon, 27 Oct 2008 14:58:30 -0700, "Mike Schilling"
> <mscottschilling@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.

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.

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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> 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

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
> [... concerning Calendar.getInstance() ...]
> 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.

-- 
Eric.Sosman@sun.com

Lew wrote:
> 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. 

Mike Schilling wrote:
> Lew wrote:
>> 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. 

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

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.

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

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.

>               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

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

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 !

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

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.

Arab, Chines and Japanese calendars are very different from Gregorian
and Julian calendars.

Arne

Harold Yarmouth wrote:
> 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

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>>> 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.

Just name 10 libraries.

Arne

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.

And note that even that usage is working fine, if the programmer
reads the docs.

Arne

Arne Vajhøj wrote:
> 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.

Arne Vajh�j wrote:
> 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.)

Arne Vajh�j wrote:
> 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.

Joshua Cranmer wrote:
> 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.

Lew wrote:
> 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.

Arne Vajh�j wrote:
> Mike Schilling wrote:
>> Lew wrote:
>>> 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. 
> 
> 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.

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.

Arne Vajh�j wrote:
> 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.

Arne Vajh�j wrote:
> 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.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> 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.

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.

Arne Vajh�j wrote:
> 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.)

Arne Vajh�j wrote:
>> 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.)

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? Nice to know that 
you're so culturally sensitive in ignoring such major calendars as the 
Chinese calendar, Arabic calendar, and Hebrew calendar.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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, 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

> 
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

Harold Yarmouth wrote:
> 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Lew wrote:
>> 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

Arne Vajhøj wrote:
>> 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

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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.

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"

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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.)
Bad design != bug
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/>

Daniel Pitts wrote:
> 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

Lew wrote:
> Daniel Pitts wrote:
>> 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?

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. 

Lew wrote:
> Daniel Pitts wrote:
>> 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?

Calendar and Date are not very elegant created.

I do not see Paulmouth's problem as a problem though.

Arne

Mike Schilling wrote:
> Lew wrote:
>> Daniel Pitts wrote:
>>> 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?
> 
> 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. 

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

On Thu, 30 Oct 2008 20:31:22 -0400,
	Lew <noone@lewscanon.com> wrote:
> Daniel Pitts wrote:
>> 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?

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?

Arne Vajhøj wrote:
> Lew wrote:
>> Daniel Pitts wrote:
>>> 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?
> 
> Calendar and Date are not very elegant created.
> 
> I do not see Paulmouth's problem as a problem though.

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

Lew wrote:
> Daniel Pitts wrote:
>> 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?

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


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

     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
esosman@ieee-dot-org.invalid

Eric Sosman 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
> 
>     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.

"For every complex problem, there is a solution that is simple, neat,
and wrong."

:-)

Arne

On Oct 30, 11:00=A0pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> Lew wrote:
>
> > I tend to agree about Date. =A0Calendar is a bit klunky, perhaps innate=
ly
> > due to the irrational psychosocial nature of human calendars, and its
> > 'clear()' method is truly confusing. =A0So I agree that it has flaws, b=
ut
> > the blanket condemnation of Calendar as "flawed" implies that it is far
> > less useful than it really is.
>
> =A0 =A0 =A0Here are two things I've observed:
>
> =A0 =A0 =A01) 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.

Owen Jacobson wrote:
> 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

Owen Jacobson wrote:
> 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
esosman@ieee-dot-org.invalid

Lew wrote:
>>
> 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. [a lot
> 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.

Joshua Cranmer wrote:
> 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.

John W Kennedy wrote:
> 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.

Lew wrote:
>> 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.

Joshua Cranmer wrote:
> 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.

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> 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?

For "the most lame argument posted to cljp in 2008".

Arne

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> 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

I am not. I am unwilling to jump whenever you say "frog", given that 
you're a complete stranger, you have no authority over my whatsoever, 
and (especially) you seem to expect me to despite the first two things.

The original problem discussed in this thread has long since been 
solved. I see no constructive purpose in it continuing further.

So let's just walk away from this, agreeing to disagree on some issues.

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Lew wrote:
>>>> 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.

It has to include the milliseconds because it has to convert
to and from Date which contains milliseconds.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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.)

Well - nobody besides you seem to find it surprising.

I don't think SUN should design the API after the stupidest man
on earth.

Arne

Harold Yarmouth wrote:
> Lew wrote:
>> 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.

Lew was not referring to himself as a "god", but the one who wrote the 
linked article (i.e., Joshua Bloch, a key Java developer). I think it is 
safe to say that those who wrote Java are better authorities on it than 
you or I.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Lew wrote:
> 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.

MySQL TIMESTAMP semantics are very common. It is just usually
called something else.

Arne

Lew wrote:
> 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.

That is either completely irrelevant to this newsgroup's topic, or a 
veiled insult AND completely irrelevant to this newsgroup's topic.

> Ancd you aren't going to thank him for anything.

That is not your place to decide. Who do you think you are, anyway -- God?

Lew wrote elsewhere in this same thread:
> 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.
> When the gods speak, mortals should listen.

I'll take that as a "yes".

There's a cell waiting for you at Bellevue, and another one being warmed 
up in a different place for after you die, I suspect.

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>>> 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.

But making claims and not being able to substantiate them is being
a charlatan !

>                                            It is exceptionally rude and 
> uncalled-for behavior that I shall not tolerate from you or anybody else!

Well - you don't have anything to say in that matter.

> (If you insist -- almost ANY ten.)

Names please.

Arne

Daniel Pitts wrote:
> Bad design != bug

I disagree, at least past a certain point.

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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.

There are.

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

There is nothing pre-industrial about those.

And internationalization of business apps are very common.

Arne

Arne Vajh�j wrote:
> It has a set method that can set each of them individually and
> are what should have been used by Paulmouth.

Please do not misspell my name. It is not that difficult to get right. 
And if you have difficulty anyway, copy-paste is just about foolproof. I 
use it all the time myself if I run into a complex and long foreign name 
-- or one with an accented character that isn't on my keyboard. Hint, hint.

Arne Vajhøj wrote:
> I do not see Paulmouth's problem as a problem though.

That's two occurrences of the same rather improbable misspelling. I am 
now forced to suspect that you are being intentionally rude to me, 
Barney Vajhoj.

Harold Yarmouth wrote:
> "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.

Nonsense.

You can obviously not compare those two things.

Java enables people to write programs.

Java need to support multiple calendars to support people that
use those calendars.

Java needs to support sound for those that make apps that use
sound.

Java should not limit functionality due to Taleban religious
beliefs or racists that think only the Gregorian Calendar
is needed.

Arne

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> 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.

I was referring to "cultural sensitivity" to be polite in suggesting 
"You have an arrogant Anglo-Amerocentric viewpoint." There are countries 
who use non-Gregorian calendars for civil purposes, by requiring that 
the API dictate everything in Gregorian, you've essentially said "screw 
you" to said countries.

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

When viewed pedantically, the typical fiscal calendar is not even the 
same as the civil Gregorian calendar in place in most countries: March 
1, 2009 is in the same fiscal year as November 2, 2008. So if I'm doing 
calculations on a fiscal calendar, it should tell me that the two are in 
the same year, right?

Note that time is near-impossible to determine good APIs for since the 
human concept of time is not even consistent, let alone the technical 
muck designed to make it saner for human use.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Arne Vajhøj wrote:
> Lew wrote:
>> 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.
> 
> MySQL TIMESTAMP semantics are very common. It is just usually
> called something else.

Exactly.  Calling it by the wrong name is the idiosyncrasy.

-- 
Lew

Harold Yarmouth wrote:
> John W Kennedy wrote:
>> 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 are an asshole.

You are ignorant.

You seems to be a racist, but it could be just the ignorance that
gives that impression.

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

Believing that non Gregorian calendars are older and most suited
for religious purposes is either ignorant or racists.

Your distinction between PL and BLL is irrelevant because noone
has made any distinction between those so far and wrong, because
BLL most certainly can need calendar info.

BTW, it is worth mentioning that the .NET framework includes
several calendars:

EastAsianLunisolarCalendar
GregorianCalendar
HebrewCalendar
HijriCalendar
JapaneseCalendar
JapaneseLunisolarCalendar
JulianCalendar
KoreanCalendar
KoreanLunisolarCalendar
PersianCalendar
TaiwanCalendar
TaiwanLunisolarCalendar
ThaiBuddhistCalendar
UmAlQuraCalendar

They know how important i18n is for business apps.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> 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.
> 
> 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. 

You mean that you don't know any examples and that you just made up your
claim and you don't have the character to admit it !

Arne

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Lew wrote:
>>> 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.
> 
> Lew was not referring to himself as a "god", but the one who wrote the 
> linked article (i.e., Joshua Bloch, a key Java developer). I think it is 
> safe to say that those who wrote Java are better authorities on it than 
> you or I.

Correct.  The coincidence of last name is irrelevant to my characterization of 
Joshua Bloch as a "god" of Java.

-- 
Lew Bloch

Harold Yarmouth wrote:
> Lew wrote:
>> 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.

Well - the last one is something you added later.

(because you have not understood that Calendar indeed has polymorphic
requirements, then you apparently thought it would support your case)

But it is already proven that your rule is not followed in the
Java API and you have not been able to mention any library that
does.

Arne

Lew wrote:
> Correct.  The coincidence of last name is irrelevant to my 
> characterization of Joshua Bloch as a "god" of Java.

No family relationship ?

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Mike Schilling wrote:
>>> Lew wrote:
>>>> 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. 
>>
>> 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.
> 
> 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.

There are 9 no-arg getInstance methods among those 44 - none of those 9
are singletons either.

Arne

Harold Yarmouth wrote:
> Lew wrote:
>> Joshua Cranmer wrote:
>>> 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.

Which is why all Java developers above the absolute beginners level read
the complete API docs.

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

You are completely missing the point. Using a factory excatly
separate responsibilities.

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

Which has been proven to be wrong.

Arne

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> 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.

Your mistake !

Arne

Eric Sosman 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
> 
>     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.

I can sum up the problem in one quick sentence: failure to separate two 
areas of responsibility, "internal representation and arithmetic" and 
"UI presentation". The former can be done very cleanly, using either a 
standard Gregorian calendar in the UTC+0000 time-zone or just using 
seconds since the epoch or whatever. The latter then boils down to 
converting between a locale-dependent representation and the internal one.

Systems with such a division can potentially do a very good job of 
avoiding Y2K bugs, bugs when the hour gets set back in the fall, and 
similar problems. In particular, when internal times are stored in a 
fixed time zone, or in seconds since the epoch, the internal clock never 
jumps backwards by an hour and no two events have the same timestamp 
without being genuinely (close to) simultaneous. Only the display in the 
UI is affected by DST transitions and such.

DST transitions end up having either of two interesting UI effects.

One would be for the date/time combos after the transition to be 
affected in their presentation, which could result in e.g. an 
interactive program listing or appointment-book app showing

11:00 PM   12:00 PM   1:00 AM   1:00 AM   2:00 AM

with different things under the two "1:00 AM" columns. Or something in 
the same general vein. Different hours with the same displayed name. If 
the user can click to manipulate objects, and not just get a "handle" on 
them by typing a name, it won't cause too much trouble.

The other would be to have the presentation of ALL dates switch. A 
simple switch-the-system-locale-at-DST-transition system would cause 
this, and then the display above would go from 11 until 3, except that 
if you did something after the DST transition to make it redraw itself, 
it would then show 10 until 2. At neither time would two hours have the 
same name, but you could set something to 2 PM the next afternoon in 
such an interface and have it change overnight to be at 1 PM, which is 
why I'd favor the first method for handling DST over the second.

(The forward transition in the spring would have similar, but milder 
effects. In the second case, that 2PM appointment would jump to 3PM, 
which is equally bad. In the first case, the displayed hour names would 
skip over one name you'd normally expect, rather than duplicate one. 
Here is where the effect is milder, because typing in a time around 
"spring forward" won't sometimes be ambiguous unlike in the "fall back" 
case. But a UI that lets the user click on objects to manipulate them 
without having to type in their names does not suffer much from such 
ambiguity anyway.)

Date arithmetic would yield simple and predictable results with a proper 
separation of content and presentation concerns: adding 30 days, for 
example, would move Jan. 30 to Feb. 29 on leap years and Mar. 1 
otherwise. If there was an "add one month", it would have to cope 
somehow (say, by snapping the day to the last day of the month if it 
would otherwise go over) and its behavior at corner cases would have to 
be properly documented. (That results in Jan. 30 plus 1 month being 
either Feb. 29 or Feb. 28, depending on the leap-year status of the year 
of the date being manipulated.)

Often, the application may need a bit of its own localized logic to deal 
with figuring out what is the "next business day" or similarly. This 
should be cleanly separated from the core Date class that concerns 
itself with merely representing dates and times and with "next day" and 
similarly.

Possibly, cleanest would be to have seconds (or milliseconds, or 
whatever) since the epoch as the core time type's representation and all 
notions of months, days, years, or other such be in the presentation 
classes rather than the core Time class. One might even then have a Date 
class that is polymorphic and localized, and that wraps a Time object. 
It could be set from a Time object and its Time object retrieved, as 
well as have formatting, parsing, and other methods and methods like 
addDays. You'd also want Duration objects, built on an integer, with 
DateDifference the localized wrapper. Date subtraction would produce 
DateDifference objects, and DateDifferences could be summed or 
subtracted, multiplied by scalar integers, and added to or subtracted 
from Dates, for any arithmetic involving fixed intervals. Under the 
hood, long arithmetic is being performed. Date methods might also exist 
to add "n months", "n years", or similarly, that deal with Feb. 29 
appropriately, and perhaps even a "nextBusinessDay" method could exist, 
given the locale objects were specific and detailed enough to have each 
area's local holidays and business practises mapped. Some areas have 
Friday and Saturday as the weekend and a Saturday sabbath, for example. 
States in the US have civic holidays other states lack.

At least all of the "messy" bits would be swept into a class whose 
responsibility was to deal with them and to manage presentation and 
user-input of dates, while simple under-the-hood timekeeping would be 
managed by something clean and simple.

I think they tried to do something like that with Date/Calendar, but 
ended up giving Calendar the job of being Date's primary builder as 
well, instead of Date having its own simpler means of constructing it 
that a) used the default international standard representations, a 
Gregorian calendar in the GMT timezone as I understand it, and b) wasn't 
deprecated.

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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?

Very simple answer.

Because there are only one StringBuilder and multiple Calendar's.

> The only explanation I can think of, besides sheer perversity, is 
> because they gave one class multiple responsibilities.

No. See above.

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

Try read the documentation of the Calendar class again.

You seem to have missed some methods.

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

If you care about milliseconds you need to set milliseconds.

And there is a method for that.

> And that, by itself, is sufficient to demonstrate conclusively that a 
> design flaw exists.

No - it only proves that programmers that does not read the
documentation produce lousy code.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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 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.
> Yes, it is.

Glad you agree with me.

>> 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 am an experienced programmer

Sorry - nobody will believe that.

You don't read documentation.

You don't understand object oriented principles.

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

You did. See above.

>> Read up on "is a" principle.
> 
> Stop being rude and condescending. Do not bark orders at me. Or I will 
> do the same to you. Got it?

I got it that you do not even know about the "is a" principle.

You really should start reading.

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

No.

You have completely misunderstood what calendar classes does.

Calendars are much more different than just timezone and
language for names.

Arne

Harold Yarmouth wrote:
> Lew wrote:
>> Ancd you aren't going to thank him for anything.
> 
> That is not your place to decide. Who do you think you are, anyway -- God?
> 
> Lew wrote elsewhere in this same thread:
>> 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.
>> When the gods speak, mortals should listen.
> 
> I'll take that as a "yes".

Another good example of where you completely misses the point.

Arne

Harold Yarmouth wrote:
> Daniel Pitts wrote:
>> Bad design != bug
> 
> I disagree, at least past a certain point.

You may disagree.

But that does not change the fact that if the code follow
the specification then it is not a bug.

Arne

Harold Yarmouth wrote:
> Lew wrote elsewhere in this same thread:
>> evidence that 'getX' factories don't necessarily imply singletons. 
>> When the gods speak, mortals should listen.
> 
> I'll take that as a "yes".

Missing in that quote is the fact that you took out a line. Here is the
text, /in entirety/ :

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

It is obvious to me that Lew was referring to the person whose text was 
linked to was equivalent in status to a god.

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> 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.

Calendar is a case where core action code is locale-dependent, just like 
lexicographical ordering. The interaction of "this time, next year" 
depends heavily on what calendar we're talking about (it's different for 
solar calendars and lunar calendars), just like where to stick "é" in a 
list.

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

Do you agree or disagree with the statement "The Calendar class fails to 
live up to its contract"?

If it fails to live up to its contract, then it is a bug; no one will 
disagree to that statement, I think.

If it lives up to its contract and the contract is conceptually flawed, 
then there is disagreement as to whether or not it's a bug. The point as 
to whether design flaws are bugs is one that I will not try to debate as 
there is no hope on resolution.

Note, though, that the question of "flawed contracts" is still open.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Lew wrote:
>> Correct.  The coincidence of last name is irrelevant to my 
>> characterization of Joshua Bloch as a "god" of Java.

Arne Vajhøj wrote:
> No family relationship ?

None of which I am aware.

Ultimately all humans are related.  Those with the same surname might belong 
roughly to the same tribe - in that sense those the surname "Bloch" are 
related to those with the surname "Cohen", but these are trivial examples of 
"family relationship" and not, I assume, what you meant.  Otherwise, I am not 
related to any of the gods of Java.

Other than being one myself, of course.

-- 
Lew

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-2123816485-1225730270=:7571
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 2 Nov 2008, Arne Vajh�j wrote:

> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> 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?
>
> For "the most lame argument posted to cljp in 2008".

Can trolls even be nominated for that?

tom

-- 
Tubes are the foul subterranean entrails of the London beast, stuffed
with the day's foetid offerings. -- Tokugawa
---910079544-2123816485-1225730270=:7571--

Lew wrote:
> Lew wrote:
>>> Correct.  The coincidence of last name is irrelevant to my 
>>> characterization of Joshua Bloch as a "god" of Java.
> 
> Arne Vajhøj wrote:
>> No family relationship ?
> 
> None of which I am aware.

Ah well.

He could have been your cousin or something.

Arne

Tom Anderson wrote:
> On Sun, 2 Nov 2008, Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> Arne Vajh�j wrote:
>>>> 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?
>>
>> For "the most lame argument posted to cljp in 2008".
> 
> Can trolls even be nominated for that?

Ooops.

No.

Rule number 5 explicit prohibits giving the award to a troll.

Sorry about that.

Arne

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Daniel Pitts wrote:
>>> Bad design != bug
>>
>> I disagree, at least past a certain point.
> 
> You may disagree.
> 
> But that does not change the fact that if the code follow
> the specification then it is not a bug.

If the code follows the specification, then there is no bug *in the 
code*. There may still be a bug elsewhere. The code is not the whole of 
a computer program; there is also the design and specification, and 
those themselves may have flaws of their own, as is well known.

Eric Sosman wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>> [... concerning Calendar.getInstance() ...]
>> 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.

No such decision is logically required to get someone a date builder 
object, though.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> 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.)
> 
> Well - nobody besides you seem to find it surprising.

That is clearly a lie; Mike Schilling also finds the behavior in 
question odd and even describes it as "a flaw" in 
<f%sOk.4335$D32.2619@flpi146.ffdc.sbc.com>.

> I don't think SUN should design the API after the stupidest man
> on earth.

Neither do I. Whoever that may turn out to be, he surely does not 
program Java, and dumbing down the design for him would be a bad idea 
even if it turned out that he did.

However, I wasn't suggesting that Sun do so. I was suggesting that Sun 
design it to make sense and work reasonably well, without flaws of the 
sort Mike Schilling noted in his post.

You were the one who introduced "the stupidest man on earth" into this 
discussion, one in which he (whoever he is) appears not to be relevant.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>>> 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.
> 
> But making claims and not being able to substantiate them is being
> a charlatan !

Yes, so you, of course, are a charlatan, for making so many 
unsubstantiated and negative claims about me.

I, of course, am not one.

>>                                            It is exceptionally rude 
>> and uncalled-for behavior that I shall not tolerate from you or 
>> anybody else!
> 
> Well - you don't have anything to say in that matter.

Oh, yes, I do. I just DID say something, didn't I?

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> "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.
> 
> Nonsense.

No. The person posting nonsense here is you.

> You can obviously not compare those two things.

Sure I can. I just did.

> Java enables people to write programs.
> 
> Java need to support multiple calendars to support people that
> use those calendars.

And it can do so in a UI-oriented class. DateFormat might be expanded to 
provide such functionality. Or a CalendarFormat class added.

> Java should not limit functionality due to Taleban religious
> beliefs or racists that think only the Gregorian Calendar
> is needed.

It is not racist to think that only the Gregorian calendar is needed. It 
is simple pragmatism: only the Gregorian calendar is ordinarily *used*. 
It covers the vast majority of programming needs, since it's a defacto 
international standard throughout the developed world and throughout 
international commerce. These observations are not racism. "People of 
Arne Vajhoj's nationality are all stupid and nasty and brutish" would be 
racism, were I to actually suggest such a thing in seriousness, but I 
haven't, have I?

Furthermore, we were discussing the core business-logic classes. Those 
should use a single time standard, ideally, say a Gregorian calendar 
with the UTC+0000 time-zone. Alternative ways of displaying dates to the 
user and of parsing dates from the user belong in a separate utility class.

Elsewhere in this thread a link to a JSR was posted. That JSR describes 
how to do this right, or at least better, and still support non-standard 
calendars for those who see a use for them.

Note also that never have I suggested, though you keep insinuating 
otherwise, that such users should not be able to use alternative 
calendars. I just questioned including them in core Java, and especially 
involving them in the core Date class and its builder object rather than 
putting them somewhere more peripheral.

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>>> 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.
> 
> I was referring to "cultural sensitivity" to be polite in suggesting 
> "You have an arrogant Anglo-Amerocentric viewpoint."

You should not suggest an insulting lie about me at all. In future, don't.

> There are countries 
> who use non-Gregorian calendars for civil purposes, by requiring that 
> the API dictate everything in Gregorian, you've essentially said "screw 
> you" to said countries.

Bull. I only suggested that the CORE part of the API do everything with 
one standard time representation. There can be a translation class used 
to interface to the user using whatever means of measuring and naming 
times that they prefer, of course, but the core should be something 
simple and world-standard, like a Gregorian calendar or seconds since 
the epoch or whatever.

Someone else posted a link to a JSR that details how to do this right, 
or at least better.

>> 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.
> 
> When viewed pedantically, the typical fiscal calendar is not even the 
> same as the civil Gregorian calendar in place in most countries: March 
> 1, 2009 is in the same fiscal year as November 2, 2008.

The last time I checked, fiscal calendars vary from organization to 
organization. There users have to supply their own code to translate 
from a standard time format into their local fiscal calendar.

> So if I'm doing calculations on a fiscal calendar, it should tell
> me that the two are in the same year, right?

Yes, though the core Date class won't do so.

If Calendar's sole purpose was this sort of translation there wouldn't 
be a problem. But Calendar is also the "DateBuilder" because Date has no 
non-deprecated methods or constructors to directly build a standard date 
using standard units, say from one encoded in such units in a file or a 
network packet.

> Note that time is near-impossible to determine good APIs for since the 
> human concept of time is not even consistent, let alone the technical 
> muck designed to make it saner for human use.

See that JSR.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> John W Kennedy wrote:
>>> 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 are an asshole.
> 
> You are ignorant.

I am neither, and you are a liar.

> You seems to be a racist, but it could be just the ignorance that
> gives that impression.

I am neither, and you are a liar.

If you have nothing further to say ABOUT JAVA, then please shut up. 
Posts that consist largely or solely of personal attacks are off-charter 
and unwelcome here.

>> 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.
> 
> Believing that non Gregorian calendars are older and most suited
> for religious purposes is either ignorant or racists.

No, it is not. It is simply an observation of a statistically-true fact.

If you think it's "racist" that the international business and trade 
standard is to use a Gregorian calendar (and often UTC+0000) to conduct 
business, then you must think that nearly the entire business world is 
racist, from American CEOs to Saudi oil barons and Japanese automotive 
magnates and Korean electronics corporate VPs of marketing.

I rather suspect that it is *you* who is racist -- anti-American and 
anti-globalization. Even though it really just makes sense to pick some 
standard to use in international-trade settings so as to simplify 
communications.

I suppose you'd also brand a person a racist for making the observation 
that English has become the de facto lingua franca of world commerce?

> Your distinction between PL and BLL is irrelevant

No, your rude and uncalled-for personal attacks are irrelevant and do 
not belong in this newsgroup. Now git!

> BTW, it is worth mentioning that the .NET framework includes
> several calendars:
> 
> EastAsianLunisolarCalendar
> GregorianCalendar
> HebrewCalendar
> HijriCalendar
> JapaneseCalendar
> JapaneseLunisolarCalendar
> JulianCalendar
> KoreanCalendar
> KoreanLunisolarCalendar
> PersianCalendar
> TaiwanCalendar
> TaiwanLunisolarCalendar
> ThaiBuddhistCalendar
> UmAlQuraCalendar
> 
> They know how important i18n is for business apps.

It is. And it belongs in the UI layer. Times should be something simple, 
like nanoseconds since the epoch, under the hood.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> 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.
> 
> 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.
> 
> There is nothing pre-industrial about those.

Sure there is. The country in which the industrial revolution began used 
the Gregorian calendar, and as a result it more or less got standardized 
on. That same country spoke English, and as a result English also more 
or less got standardized on.

You wouldn't recommend that String support translation into different 
languages, would you? No, that belongs in the outer parts of the 
program, using MessageBundle and similarly.

Likewise, conversion of the internal representation of time to and from 
a particular localized representation belongs in the periphery of the 
program, and the support classes to do so should be clearly distinct 
from the core classes that are merely used to work with 
network/file/internal time representations, compare these for equality 
and order, and perform duration arithmetic upon them.

See that JSR a link to which somebody else posted. It gets this more or 
less exactly right, unlike you. You therefore might find it quite 
educational.

> And internationalization of business apps are very common.

Of their user interface layers, yes. (Imagine the chaos that would ensue 
if the back-end DB had some dates in different time zones, some in the 
Julian calendar, and so forth. This isn't done, which further reinforces 
my point.)

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Lew wrote:
>>> 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.
> 
> Lew was not referring to himself as a "god"

It sure looked like he was. At least to anyone who wasn't well versed in 
Latin. There was a piece of (abbreviated, at that) Latin in there that 
might have indicated otherwise, but even if it did, who here is fluent 
in that dusty old language?

(I suppose you're now going to falsely accuse me of being a racist for 
calling Latin "dusty" and "old".)

> I think it is safe to say that those who wrote Java are better
> authorities on it than you or I.

All the more reason for you to defer to the wisdom of that JSR for 
overhauling the date and time classes. Since that JSR agrees with me, 
that means you should stop attacking me.

Lew wrote:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>>> Lew wrote:
>>>> 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.
>>
>> Lew was not referring to himself as a "god", but the one who wrote the 
>> linked article (i.e., Joshua Bloch, a key Java developer). I think it 
>> is safe to say that those who wrote Java are better authorities on it 
>> than you or I.
> 
> Correct.

Then you should have been more clear. In particular, you should not 
encrypt parts of your post that were apparently crucial to interpreting 
it as you'd intended by writing those parts in Latin of all the corny 
things.

And you're still an arrogant and presumptuous git.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Lew wrote:
>>> 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.
> 
> Well - the last one is something you added later.

No, it's something I made explicit later, but had implied from the start.

> (because you have not understood

You will stop being insulting towards me in public. I clearly understand 
better than you what is logically required for a simple and basic 
date-builder object and what would be extraneous.

> But it is already proven that your rule is not followed in the
> Java API and you have not been able to mention any library that
> does.

I mentioned that an awful lot of them do, and I'll thank you to stop a) 
accusing me of being a liar and b) lying about me!

Arne Vajh�j wrote:
> You mean that you don't know any examples and that you just made up your
> claim and you don't have the character to admit it

No, I do not. I mean that I know of too many to list and that YOU are 
the one "just making things up", including every single unpleasant 
assertion that you've publicly made about me.

This newsgroup is supposed to be about Java programming, not about who 
is or isn't a liar, a nincompoop, or whatever-else.

I'll thank you to begin abiding by this newsgroup's charter and 
confining your discussions, and especially your wild speculations and 
guesses, to the topic of Java.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> 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.
> 
> There are 9 no-arg getInstance methods among those 44

I also never said I meant "only in the core Java API". I meant "in Java 
code in general", as in ALL of it.

Please stop putting words in my mouth, or otherwise twisting what I've 
said, in your zeal to "prove" that I'm whatever sort of idiot or liar 
you seem to want to believe I am.

Not only is it evil, it's incorrect.

Not only is it incorrect, it's not even on topic in this newsgroup.

This is not the appropriate forum for you to vent your personal issues. 
Find somewhere more appropriate or shut the heck up.

Arne,

You're wasting your time arguing with this idiot. Haven't you noticed the
remarkable similarity to the nuisance who previously used the ID of
b.phillips@a5723mailhost.net? Even down to the same ISP, same version of
Thunderbird and various other tells. Presumably he's popped up with a new
identity to get around kill-files. 

It would be prudent to add this new identity to the same kill-file.

-- 
Nigel Wade

On Nov 4, 6:28=A0am, Nigel Wade <n...@ion.le.ac.uk> wrote:
> Arne,
>
> You're wasting your time arguing with this idiot. Haven't you noticed the
> remarkable similarity to the nuisance who previously used the ID of
> b.phill...@a5723mailhost.net? Even down to the same ISP, same version of
> Thunderbird and various other tells. Presumably he's popped up with a new
> identity to get around kill-files.
>
> It would be prudent to add this new identity to the same kill-file.

Arne is simply elucidating the point made by at least one of the gods
of Java, Mr. Bloch, /op. cit./, that 'getX()' factory methods
absolutely do not implicitly or explicitly denote the return of a
singleton, although sometimes they do return a singleton.  There are
many others who read this group besides "Harold" (not his real name)
who can benefit by having the truth, who otherwise might be misled by
the misinformation promulgated to the contrary.

--
Lew

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> Daniel Pitts wrote:
>>>> Bad design != bug
>>>
>>> I disagree, at least past a certain point.
>>
>> You may disagree.
>>
>> But that does not change the fact that if the code follow
>> the specification then it is not a bug.
> 
> If the code follows the specification, then there is no bug *in the 
> code*. There may still be a bug elsewhere. The code is not the whole of 
> a computer program; there is also the design and specification, and 
> those themselves may have flaws of their own, as is well known.
A flaw isn't necessary a bug.  I happen to agree that the Calendar and 
Date classes are highly flawed, but not buggy.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>>> 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.
> 
> Calendar is a case where core action code is locale-dependent, just like 
> lexicographical ordering.

Still split responsibilities. String.compareTo() is not locale-dependent 
(imagine the chaos if it were!) and StringBuilder's behavior is not 
locale-dependent; for locale-dependent lexicographic ordering of strings 
we have a separate class dedicated to the purpose, Collator.

A similar design should probably have been chosen for dates and times -- 
Date and its no-frills builder (probably DateBuilder rather than 
Calendar) using a default set of behaviors based on the commonest case 
(Western calendar, UTC+0000 time-zone) and a separate class for 
locale-dependent transformations and actions (probably Calendar, but 
maybe with DateFormat folded in and certainly with a DateBuilder 
separated out).

We'd then have this correspondence (with DateFormat *not* folded in):

String             Date              core ops
StringBuilder      DateBuilder       get, no-frills
MessageBundle      DateFormat/etc.   get with locale sensitivity
Writer w/encoding  DateFormat/etc.   write with locale sensitivity
Collator/etc.      Calendar          other operations w/locale sens.

This would give a better separation of responsibilities on the Date 
side, mirroring the current division on the String side.

> The interaction of "this time, next year" depends heavily on what
> calendar we're talking about (it's different for solar calendars
> and lunar calendars), just like where to stick "é" in a list.

The output of "one day in the future" or similarly does not.

(Also, please point out any business, especially a web business, that 
uses a lunar calendar to reckon invoice overdue-ness, timestamp server 
logs, track shipments, determine office hours of operation, timestamp 
internal email, etc. -- I'd really like to know of one. If you can 
actually find one.)

> Note, though, that the question of "flawed contracts" is still open.

If part of its contract is "providing the simplest way to get a specific 
date in international standard form" then it does not make that as 
simple as possible. That might be considered a flaw in how well it 
implements that particular function. But it really does look to me like 
that functionality belongs separate from the locale-dependent 
functionality, or at least fixed up so the output Dates aren't prone to 
having a random tiny variation from one another.

I'd argue that, at least, the most-specific-possible "set" method (just 
by being so) has an implied contract to completely determine the output. 
If so, that contract clearly IS violated.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Lew wrote:
>>> Joshua Cranmer wrote:
>>>> 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.
> 
> Which is why all Java developers above the absolute beginners level

These constant jabs and digs are becoming tiresome. If for some reason 
you cannot be civil, please be silent.

>> 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.
> 
> You are completely missing the point.

No, I am not; you are.

If for some reason you cannot be civil, please be silent.

>> 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.
> 
> Which has been proven to be wrong.

No, it has not.

If for some reason you cannot be civil, please be silent.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>>> 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.
> 
> Your mistake !

No. If there is any mistake there, it was made by the IDE's developers, 
and I was not involved. That IDE is NetBeans, so if you think their 
built-in documentation display should behave differently, I respectfully 
suggest that you take it up with them and stop insulting me in public.

Regardless -- if for some reason you cannot be civil, please be silent.

Arne Vajh�j wrote:
>> 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?
> 
> Very simple answer.
> 
> Because there are only one StringBuilder and multiple Calendar's.

That's begging the question.

>> The only explanation I can think of, besides sheer perversity, is 
>> because they gave one class multiple responsibilities.
> 
> No.

Yes. They mixed "just get me a stock Date for this day, month, and year" 
functionality and "do all these whiz-bang locale-dependent presentations 
and manipulations" functionality in one place. Whereas for Strings we 
have separate StringBuilder (simple construction of an instance), 
Collator (locale-dependent collations), MessageBundle (get 
locale-dependent strings), various I/O classes with character encodings 
(input and output in a locale-dependent way), and so on. With Date, they 
stuffed almost everything for the above sorts of functionality into 
Calendar, which became a mess, and a little bit into DateFormat.

> Try read the documentation of the Calendar class again.

Try read Emily fucking Post again! Your rudeness is becoming incredibly 
tiresome. Learn to be polite in public!

>> 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.
> 
> If you care about milliseconds you need to set milliseconds.

However, if you DON'T care, the above should completely determine the 
output. Otherwise you get surprises if you later test them for equality.

Really, set(year, month, day, hour, minute, second) done twice with the 
same values should produce results that compare equal. It really is that 
simple, and in all of this arguing over locales and other nonsense, that 
one point, the ORIGINAL point, has somehow gotten overlooked.

>> And that, by itself, is sufficient to demonstrate conclusively that a 
>> design flaw exists.
> 
> No

Yes. See above.

> programmers that does not read the documentation produce lousy code.

My code is not lousy.

If for some reason you cannot be civil, please be silent.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Lew wrote:
>>> Ancd you aren't going to thank him for anything.
>>
>> That is not your place to decide. Who do you think you are, anyway -- 
>> God?
>>
>> Lew wrote elsewhere in this same thread:
>>> 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.
>>> When the gods speak, mortals should listen.
>>
>> I'll take that as a "yes".
> 
> Another good example of where you completely misses the point.

NO. I do not, and I must insist that you stop this gratuitous rudeness 
at once. This latest post of yours does not contain a single piece of 
Java-related information that wasn't quoted from someone else. The ONLY 
original material in it is a personal attack. That is completely 
unacceptable.

If for some reason you cannot be civil, please be silent!

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Lew wrote elsewhere in this same thread:
>>> evidence that 'getX' factories don't necessarily imply singletons. 
>>> When the gods speak, mortals should listen.
>>
>> I'll take that as a "yes".
> 
> Missing in that quote is the fact that you took out a line.

A line that could not be interpreted without knowing Latin, and that 
therefore is irrelevant to the matter of *how that paragraph would be 
perceived by some guy reading it*.

>> /op. cit./.
>>
>> <http://www.ddj.com/java/208403883>
> 
> It is obvious to me that Lew was referring to the person whose text was 
> linked to

Well, perhaps you know Latin and it actually was obvious TO YOU. 
However, most people do not know what any given piece of Latin means, 
especially when it's abbreviated instead of spelled out.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> 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 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.
>> Yes, it is.
> 
> Glad you agree with me.

I do not! And that is a complete misquotation of what I wrote.

This is what I actually wrote:

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

As you can CLEARLY see, I was "agreeing" that you had forgotten to check 
your confrontational attitude at the door, not agreeing with your 
vicious and uncalled-for personal attacks.

If you EVER pull a dishonest stunt like that little bit of "creative 
quoting" AGAIN I will have your HEAD. Have I made myself clear???

>> I am an experienced programmer
> 
> Sorry - nobody will believe that.

Is that intended as a threat?

If this is a declaration of your intent to smear my professional 
reputation in public if I don't knuckle under to some as-yet-unstated 
set of demands, well all I can say is "see you in court". It will be a 
defamation lawsuit if you make good on that threat. And I won't knuckle 
under, regardless.

Regardless, you are in no position to assert what other people will or 
will not believe. Other people will make up their own minds and I doubt 
you are anywhere near as influential as you apparently think you are.

> You don't read documentation.

I do.

> You don't understand object oriented principles.

I do. Better than you do, apparently. You clearly don't get separation 
of concerns, nor when to use names like "getInstance", versus 
"newInstance" or a constructor. I do, and you got mad when you found out 
that I know some things you don't. And threw a childish temper-tantrum 
in public, hurling abuse and name-calling and generally behaving like a 
six-year old that got told he couldn't have some candy because his 
grades were too poor on his report card.

>>> You do not let Calendar be GregorianCalendar and then ask all
>>> other Calendars to overwrite most methods.
>>
>> Who said anything about that?
> 
> You did.

No, I said that the object charged with the responsibility of being the 
no-frills Date builder should be simple and straightforward, and need 
not be polymorphic (and thus should not, given the simplicity requirement).

>>> Read up on "is a" principle.
>>
>> Stop being rude and condescending. Do not bark orders at me. Or I will 
>> do the same to you. Got it?
>
> I got it

Good.

> you do not even know about the "is a" principle.

A lie.

It's just that it's not relevant to the issue of how to implement a 
simple Date builder, anymore than it's relevant to the implementation of 
StringBuilder.

> You really should start reading.

Since you evidently had nothing civil or Java-related to say here, 
perhaps you should have kept your trap shut.

>>> 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.
> 
> No.

Yes.

> You have completely misunderstood

No. YOU have completely misunderstood the purpose of this newsgroup. Its 
purpose is to enable intelligent adults discuss Java in a civil and 
levelheaded fashion, not to enable little children whose parents don't 
monitor their use of the Internet to flame and get into childish pissing 
contests.

Now pull the plug and tell your Mommy you want a sledgehammer for 
Christmas so you can smash up your modem and eat it, and then, without 
the distraction of coming here to post gratuitously insulting and 
largely non-Java-related trash-talk at other people, focus on your 
studies and improve your grades so you can ace fourth-grade Reading 
Comprehension and, especially, not flunk English Lit *again*.

> Calendars are much more different than just timezone and
> language for names.

Calendars for use in ordinary business-programming situations are not. 
Anything else belongs outside the core date/time classes. Same way 
String does not have the functionality of Collator or MessageBundle 
built-in, nor does StringBuilder.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> 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?
> 
> For "the most lame argument posted to cljp in 2008".

Oh, no matter. I wouldn't have won that one anyway.

You might, though.

Tom Anderson wrote:
> On Sun, 2 Nov 2008, Arne Vajh�j wrote:
> 
>> Harold Yarmouth wrote:
>>> Arne Vajh�j wrote:
>>>> 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?
>>
>> For "the most lame argument posted to cljp in 2008".
> 
> Can trolls even be nominated for that?

The only troll here is Arne, whose posts "shed more heat than light" and 
seem designed to get his victims to respond in their own defense to his 
repeated public slights.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> Harold Yarmouth wrote:
>>>> Lew wrote:
>>>>> 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.
> 
> It has to include the milliseconds because it has to convert
> to and from Date which contains milliseconds.

Why? It could conceivably instead just be precise to the nearest second, 
with conversion from Date losing (usually useless) information and 
conversion to Date filling those in with zeros.

It should either do so, or provide a seven-argument set method, or the 
sixth argument set method should zero out the milliseconds. One of those 
three.

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> Missing in that quote is the fact that you took out a line.
> 
> A line that could not be interpreted without knowing Latin, and that 
> therefore is irrelevant to the matter of *how that paragraph would be 
> perceived by some guy reading it*.
> 
>>> /op. cit./.
>>>
>>> <http://www.ddj.com/java/208403883>
>>
>> It is obvious to me that Lew was referring to the person whose text 
>> was linked to
> 
> Well, perhaps you know Latin and it actually was obvious TO YOU. 
> However, most people do not know what any given piece of Latin means, 
> especially when it's abbreviated instead of spelled out.

I see a link. A link is followed by the line "When gods speak, mortals 
should listen." Does that line refer to the text immediately preceding 
it or the text a while back? In the English language, proper grammatical 
structure dictates that modifiers appear as close to the statements 
being modified as possible.

I don't know any Latin; I don't even know what `op. cit.' means (well, I 
just looked it up on Wikipedia). But that doesn't stop me from 
connecting the fact that a) the link is an important reference and b) 
the subsequent text will be making reference to the link.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Nov 5, 1:52=A0pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> Harold Yarmouth wrote:
> > Joshua Cranmer wrote:
> >> Missing in that quote is the fact that you took out a line.
>
> > A line that could not be interpreted without knowing Latin, and that
> > therefore is irrelevant to the matter of *how that paragraph would be
> > perceived by some guy reading it*.
>
> >>> /op. cit./.
>
> >>> <http://www.ddj.com/java/208403883>
>
> >> It is obvious to me that Lew was referring to the person whose text
> >> was linked to
>
> > Well, perhaps you know Latin and it actually was obvious TO YOU.
> > However, most people do not know what any given piece of Latin means,
> > especially when it's abbreviated instead of spelled out.
>
> I see a link. A link is followed by the line "When gods speak, mortals
> should listen." Does that line refer to the text immediately preceding
> it or the text a while back? In the English language, proper grammatical
> structure dictates that modifiers appear as close to the statements
> being modified as possible.
>
> I don't know any Latin; I don't even know what `op. cit.' means (well, I
> just looked it up on Wikipedia). But that doesn't stop me from
> connecting the fact that a) the link is an important reference and b)
> the subsequent text will be making reference to the link.

Exactly so.  The fact that I really am a god of Java is just a
coincidence.

--
Lew

Joshua Cranmer wrote:
>
> I don't know any Latin; I don't even know what `op. cit.' means

It's like left and right.  Or black and white.  They're op. cits.

Harold Yarmouth wrote:
[some refined variant of Twisted's usual rants]

Each posting from "Harold Yarmouth" makes me more confident that 
"Harold" is the same person who uses/has used the aliases Twisted, 
Scuzzbuster, Twerpinator, zerg, etc.
You have tried to appear reasonable, but you cannot hide your true nature.
It must be exasperating to try in vain to be accepted as a competent 
contributor, only to be tripped up by reacting the way you do. I guess 
you can't help it, so maybe I should feel sorry for you.

Lars Enderin wrote:
> Harold Yarmouth wrote:
> [some refined variant of Twisted's usual rants]
> 
> Each posting from "Harold Yarmouth" makes me more confident that 
> "Harold" is the same person who uses/has used the aliases Twisted, 
> Scuzzbuster, Twerpinator, zerg, etc.

That seems to be the logical conclusion. Two persons like that
seems highly unlikely.

Arne

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Arne Vajhøj wrote:
>>>> Harold Yarmouth wrote:
>>>>> Lew wrote:
>>>>>> 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.
>>
>> It has to include the milliseconds because it has to convert
>> to and from Date which contains milliseconds.
> 
> Why? It could conceivably instead just be precise to the nearest second, 
> with conversion from Date losing (usually useless) information and 
> conversion to Date filling those in with zeros.

That would make the milliseconds part of Date rather useless. Not a
good idea.

> It should either do so, or provide a seven-argument set method, or the 
> sixth argument set method should zero out the milliseconds. One of those 
> three.

What about providing a set method that can set milliseconds ?

Oh - it already gone one !

Just a matter of people reading the docs.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> Arne Vajh�j wrote:
>>>> 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 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.
>>> Yes, it is.
>>
>> Glad you agree with me.
> 
> I do not!

Yes usually mean agree.

> If you EVER pull a dishonest stunt like that little bit of "creative 
> quoting" AGAIN I will have your HEAD. Have I made myself clear???

You forget something. People laugh at you - they are not afraid of you.

>>> I am an experienced programmer
>>
>> Sorry - nobody will believe that.
> 
> Is that intended as a threat?

Obviously not. I was just noting a fact.

> If this is a declaration of your intent to smear my professional 
> reputation in public if I don't knuckle under to some as-yet-unstated 
> set of demands, well all I can say is "see you in court". It will be a 
> defamation lawsuit if you make good on that threat. And I won't knuckle 
> under, regardless.

Well - please sue. I guess it would be possible to find around
5000 witnesses from here that can testify that your ability to
read documentation and understanding of OOP are exceptional low.

>> You don't read documentation.
> 
> I do.

Nonsense. If you had, then this thread would not have existed.

>> You don't understand object oriented principles.
> 
> I do.

No. Your idea of having Calendar implement Gregorian calendar
and have other calendars overwrite methods clearly demonstrates that.

>>>> You do not let Calendar be GregorianCalendar and then ask all
>>>> other Calendars to overwrite most methods.
>>>
>>> Who said anything about that?
>>
>> You did.
> 
> No, I said that the object charged with the responsibility of being the 
> no-frills Date builder should be simple and straightforward, and need 
> not be polymorphic (and thus should not, given the simplicity requirement).

Not true.

You said:

# And this misdesign is somehow my fault? Why not have the default
# calendar class be Calendar itself, with overridden behavior as
# appropriate?

on October 28th.

>>>> Read up on "is a" principle.
>>>
>>> Stop being rude and condescending. Do not bark orders at me. Or I 
>>> will do the same to you. Got it?
>>
>> I got it
> 
> Good.
> 
>> you do not even know about the "is a" principle.
> 
> A lie.

Obviously not. If you did you would not have written the
nonsense you did.

> It's just that it's not relevant to the issue of how to implement a 
> simple Date builder,

What Date builder ?

As explained to you many times then Calendar is not a Date builder.

>> Calendars are much more different than just timezone and
>> language for names.
> 
> Calendars for use in ordinary business-programming situations are not. 
> Anything else belongs outside the core date/time classes. Same way 
> String does not have the functionality of Collator or MessageBundle 
> built-in, nor does StringBuilder.

Surprisingly calendar functionality belongs in the calendar classes.

Arne

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>>> Lew wrote elsewhere in this same thread:
>>>> evidence that 'getX' factories don't necessarily imply singletons. 
>>>> When the gods speak, mortals should listen.
>>>
>>> I'll take that as a "yes".
>>
>> Missing in that quote is the fact that you took out a line.
> 
> A line that could not be interpreted without knowing Latin, and that 
> therefore is irrelevant to the matter of *how that paragraph would be 
> perceived by some guy reading it*.

It is relevant for all people with sufficient skills to
do a Google search.

That means practically everyone except you.

Arne

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Lew wrote:
>>>> Ancd you aren't going to thank him for anything.
>>>
>>> That is not your place to decide. Who do you think you are, anyway -- 
>>> God?
>>>
>>> Lew wrote elsewhere in this same thread:
>>>> 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.
>>>> When the gods speak, mortals should listen.
>>>
>>> I'll take that as a "yes".
>>
>> Another good example of where you completely misses the point.
> 
> NO. I do not,

It has been clearly demonstrated that you missed that Lew was
referring to Joshua, so ...

Arne

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>> Arne Vajh�j wrote:
>>>>> Harold Yarmouth wrote:
>>>>>> Arne Vajh�j wrote:
>>>>>>> Harold Yarmouth wrote:

Tiny request... could we start trimming replies?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>>> 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?
>>
>> Very simple answer.
>>
>> Because there are only one StringBuilder and multiple Calendar's.
> 
> That's begging the question.
> 
>>> The only explanation I can think of, besides sheer perversity, is 
>>> because they gave one class multiple responsibilities.
>>
>> No.
> 
> Yes. They mixed "just get me a stock Date for this day, month, and year" 
> functionality and "do all these whiz-bang locale-dependent presentations 
> and manipulations" functionality in one place.

The Calendar has very well-defined functionality in having all the
calendar specific manipulations of Date.

 >> Try read the documentation of the Calendar class again.
 >
 > Try read Emily fucking Post again! Your rudeness is becoming incredibly
 > tiresome. Learn to be polite in public!

You will never become a programmer if you don't learn to read the docs.

 >> programmers that does not read the documentation produce lousy code.
 >
 > My code is not lousy.

But it was. You did not read the docs and your code did not work
as you wanted it to work, because of it.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> Joshua Cranmer wrote:
>>>> 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.
>>
>> Your mistake !
> 
> No. If there is any mistake there, it was made by the IDE's developers, 
> and I was not involved. That IDE is NetBeans, so if you think their 
> built-in documentation display should behave differently, I respectfully 
> suggest that you take it up with them and stop insulting me in public.

Again you completely missed the point.

You should read the docs outside of your IDE.

And I can really not see any point in contacting NetBeans
team and ask them to get a guy named Paul to fire his web
browser and read the Java docs.

Arne

Nigel Wade wrote:
> You're wasting your time arguing with this idiot. Haven't you noticed the
> remarkable similarity to the nuisance who previously used the ID of
> b.phillips@a5723mailhost.net? Even down to the same ISP, same version of
> Thunderbird and various other tells. Presumably he's popped up with a new
> identity to get around kill-files. 

I noted it.

> It would be prudent to add this new identity to the same kill-file.

He will show up with yet another identity next month.

Arne

Daniel Pitts wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>> Daniel Pitts wrote:
>>>>> Bad design != bug
>>>>
>>>> I disagree, at least past a certain point.
>>>
>>> You may disagree.
>>>
>>> But that does not change the fact that if the code follow
>>> the specification then it is not a bug.
>>
>> If the code follows the specification, then there is no bug *in the 
>> code*. There may still be a bug elsewhere. The code is not the whole 
>> of a computer program; there is also the design and specification, and 
>> those themselves may have flaws of their own, as is well known.
> A flaw isn't necessary a bug.  I happen to agree that the Calendar and 
> Date classes are highly flawed, but not buggy.

So our quibble is over the exact usages of a few words, not over 
anything substantial.

Nigel Wade wrote:
> Arne,
> 
> You're wasting your time arguing with this idiot.

No. I am not an idiot.

Though he is wasting his time. And mine. And yours and everyone else who 
reads this group.

> Haven't you noticed the remarkable similarity to the nuisance...

[rest of off-topic insults, paranoid fantasies, and other nonsense trimmed]

This is comp.lang.java.programmer. Please at least try to remain on 
topic. Not a single word of your post was about Java, Nigel.

"Lew" wrote:
> On Nov 4, 6:28 am, Nigel Wade <n...@ion.le.ac.uk> wrote:
>> Arne,
>>
>> You're wasting your time arguing with this idiot.

No, I am not an idiot. However, Arne is indeed wasting everyone's time.

>> Haven't you noticed the remarkable similarity to the nuisance...
[rest of off-topic nonsense, including insults and paranoid fantasies, 
trimmed]

Haven't you noticed that not a single word in Nigel's post was about 
Java? Clearly it should have been posted elsewhere or nowhere.

> Arne is simply elucidating the point made by at least one of the gods

There are no gods.

> /op. cit./

This is an English-language newsgroup. Most of us don't know word one of 
Latin.

> that 'getX()' factory methods absolutely do not implicitly or
> explicitly denote the return of a singleton

I never claimed that "getX()" methods do so. I claimed that, in the 
absence of an obvious reason (based on required functionality) for 
polymorphic behavior, "getInstance()" methods tend to return singletons, 
threadlocal instances, or similarly.

That this keeps being misstated by those who seek to publicly attack me, 
after this many corrections by me, can only be deliberate. Shame on you!

> There are many others who read this group besides "Harold" (not his
> real name)

You're right. "Harold" is not my real name. My real name is Harold, 
without quotation marks.

Please stop misspelling my name. You have already been told several 
times how to spell it correctly. That you continue to misspell it after 
repeated requests to stop can only indicate that you are being 
deliberately disrespectful, or perhaps willfully stupid, rather than 
making an innocent mistake. Shame on you!

> who can benefit by having the truth, who otherwise might be misled by
> the misinformation promulgated to the contrary.

The only one misleading anyone here is you, both about what I actually 
said and about what my name is. Shame on you!

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>>> Missing in that quote is the fact that you took out a line.
>>
>> A line that could not be interpreted without knowing Latin, and that 
>> therefore is irrelevant to the matter of *how that paragraph would be 
>> perceived by some guy reading it*.
>>
>>>> /op. cit./.
>>>>
>>>> <http://www.ddj.com/java/208403883>
>>>
>>> It is obvious to me that Lew was referring to the person whose text 
>>> was linked to
>>
>> Well, perhaps you know Latin and it actually was obvious TO YOU. 
>> However, most people do not know what any given piece of Latin means, 
>> especially when it's abbreviated instead of spelled out.
> 
> I see a link.

I see a URL.

> A link is followed by the line "When gods speak, mortals 
> should listen." Does that line refer to the text immediately preceding 
> it

Why would it? I have no idea what is even at that URL. I never went 
there. I have better things to do with my time than to follow links (by 
manual cut and paste, at that) from off-topic Usenet flames from 
arrogant twits.

Besides, the text gave every indication (at least to one that doesn't 
know Latin) that the URL might be that of a Latin-language Web page. I 
don't read Latin so going there would have been pointless.

> I don't know any Latin; I don't even know what `op. cit.' means (well, I 
> just looked it up on Wikipedia). But that doesn't stop me from

leaping to conclusions. Yes, I noticed that about you. Also a tendency 
to flip-flop between diametrically opposed opinions.

I think I prefer reading posts by people that are a little more ... 
well, if not *reliable* then at least *consistent*.

Lew wrote:
> Exactly so.  The fact that I really am a god of Java is just a
> coincidence.

"God" is a synonym for "Arrogant twit with too much spare time and a 
nasty temper" from my readings on the subject.

Lars Enderin wrote:
> Harold Yarmouth wrote:
> [some refined variant of Twisted's usual rants]

No. (I don't even *know* this Twisted of yours.)

> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>> Arne Vajh�j wrote:
>>>>> 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 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.
>>>> Yes, it is.
>>> 
>>> Glad you agree with me.
>>
>> I do not! And that is a complete misquotation of what I wrote.
>>
>> This is what I actually wrote:
>>
>>>>>>>>> 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.
>>
>> As you can CLEARLY see, I was "agreeing" that you had forgotten to check 
>> your confrontational attitude at the door, not agreeing with your 
>> vicious and uncalled-for personal attacks.
>>
>> If you EVER pull a dishonest stunt like that little bit of "creative 
>> quoting" AGAIN I will have your HEAD. Have I made myself clear???
>>
>>>> I am an experienced programmer
>>> 
>>> Sorry - nobody will believe that.
>>
>> Is that intended as a threat?
>>
>> If this is a declaration of your intent to smear my professional 
>> reputation in public if I don't knuckle under to some as-yet-unstated 
>> set of demands, well all I can say is "see you in court". It will be a 
>> defamation lawsuit if you make good on that threat. And I won't knuckle 
>> under, regardless.
>>
>> Regardless, you are in no position to assert what other people will or 
>> will not believe. Other people will make up their own minds and I doubt 
>> you are anywhere near as influential as you apparently think you are.
>>
>>> You don't read documentation.
>>
>> I do.
>>
>>> You don't understand object oriented principles.
>>
>> I do. Better than you do, apparently. You clearly don't get separation 
>> of concerns, nor when to use names like "getInstance", versus 
>> "newInstance" or a constructor. I do, and you got mad when you found out 
>> that I know some things you don't. And threw a childish temper-tantrum 
>> in public, hurling abuse and name-calling and generally behaving like a 
>> six-year old that got told he couldn't have some candy because his 
>> grades were too poor on his report card.
>>
>>>>> You do not let Calendar be GregorianCalendar and then ask all
>>>>> other Calendars to overwrite most methods.
>>>>
>>>> Who said anything about that?
>>> 
>>> You did.
>>
>> No, I said that the object charged with the responsibility of being the 
>> no-frills Date builder should be simple and straightforward, and need 
>> not be polymorphic (and thus should not, given the simplicity requirement).
>>
>>>>> Read up on "is a" principle.
>>>>
>>>>> Stop being rude and condescending. Do not bark orders at me. Or I will 
>>>> do the same to you. Got it?
>>>
>>> I got it
>>
>> Good.
>>
>>> you do not even know about the "is a" principle.
>>
>> A lie.
>>
>> It's just that it's not relevant to the issue of how to implement a 
>> simple Date builder, anymore than it's relevant to the implementation of 
>> StringBuilder.
>>
>>> You really should start reading.
>>
>> Since you evidently had nothing civil or Java-related to say here, 
>> perhaps you should have kept your trap shut.
>>
>>>>> 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.
>>> 
>>> No.
>>
>> Yes.
>>
>>> You have completely misunderstood
>>
>> No. YOU have completely misunderstood the purpose of this newsgroup. Its 
>> purpose is to enable intelligent adults discuss Java in a civil and 
>> levelheaded fashion, not to enable little children whose parents don't 
>> monitor their use of the Internet to flame and get into childish pissing 
>> contests.
>>
>> Now pull the plug and tell your Mommy you want a sledgehammer for 
>> Christmas so you can smash up your modem and eat it, and then, without 
>> the distraction of coming here to post gratuitously insulting and 
>> largely non-Java-related trash-talk at other people, focus on your 
>> studies and improve your grades so you can ace fourth-grade Reading 
>> Comprehension and, especially, not flunk English Lit *again*.
>>
>>> Calendars are much more different than just timezone and
>>> language for names.
>>
>> Calendars for use in ordinary business-programming situations are not. 
>> Anything else belongs outside the core date/time classes. Same way 
>> String does not have the functionality of Collator or MessageBundle 
>> built-in, nor does StringBuilder.

Please stop intentionally misquoting me. It's beginning to be a bad 
habit of yours.

> Each posting from "Harold Yarmouth" makes me more confident that
> [paranoid fantasies and other nonsense, but not a single word about
> Java]

Your behavior is incorrect.

If you have some problems with what I wrote (helpfully quoted properly 
again, above), then you address what I wrote by quoting it and adding 
your objections, caveats, or whatever as original text interspersed with 
the quoted text.

If, on the other hand, your problems are in your own head (as seems to 
be the case), or just plain have nothing to do with Java, then you don't 
post to this newsgroup about it at all.

That you didn't bother to properly quote anything from my post or 
address any specific points from my post is a strong sign that you 
should not have written a followup to it, that indeed you had no reason to.

That you didn't bother to write a single word about Java in your post is 
a strong sign that you should not have posted it to 
comp.lang.java.programmer.

At this time, I'd guess that alt.therapy would be a better fit. Your 
post seems to have been about your delusions of persecution by some 
cabal of people you seem to think I'm one of, rather than about Java.

Arne Vajh�j wrote:
> Tom Anderson wrote:
>> On Sun, 2 Nov 2008, Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>> Arne Vajh�j wrote:
>>>>> 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?
>>>
>>> For "the most lame argument posted to cljp in 2008".
>>
>> Can trolls even be nominated for that?
> 
> Ooops.
> 
> No.
> 
> Rule number 5 explicit prohibits giving the award to a troll.
> 
> Sorry about that.

Are we here to discuss Java or medieval Germanic fairy-tale monsters 
that don't really exist?

Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>>> Joshua Cranmer wrote:
>>>> Missing in that quote is the fact that you took out a line.
>>>
>>> A line that could not be interpreted without knowing Latin, and that 
>>> therefore is irrelevant to the matter of *how that paragraph would be 
>>> perceived by some guy reading it*.
>>>
>>>>> /op. cit./.
>>>>>
>>>>> <http://www.ddj.com/java/208403883>
>>>>
>>>> It is obvious to me that Lew was referring to the person whose text 
>>>> was linked to
>>>
>>> Well, perhaps you know Latin and it actually was obvious TO YOU. 
>>> However, most people do not know what any given piece of Latin means, 
>>> especially when it's abbreviated instead of spelled out.
>>
>> I see a link.
> 
> I see a URL.
> 
>> A link is followed by the line "When gods speak, mortals should 
>> listen." Does that line refer to the text immediately preceding it
> 
> Why would it? I have no idea what is even at that URL. I never went 
> there. I have better things to do with my time than to follow links (by 
> manual cut and paste, at that) from off-topic Usenet flames from 
> arrogant twits.
> 
> Besides, the text gave every indication (at least to one that doesn't 
> know Latin) that the URL might be that of a Latin-language Web page. I 
> don't read Latin so going there would have been pointless.
> 
I use Thunderbird, like you do. I just clicked on that link, which 
obviously was relevant to understand the following sentence about gods, 
even if you were not educated enough to recognize [op. cit.] as a 
reference to material mentioned elsewhere. Your refusal to look up 
background material is symptomatic and strengthens my conviction that 
you are indeed Twisted.
 From http://www.businessdictionary.com/definition/opero-citato-op-cit.html:

opero citato (op cit)
	
Definition

Reference term used usually in a footnote to refer to the title of a 
work cited in a previous footnote. Latin for, in the work cited.

I think Lew did not use it correctly, but no matter. Your response to 
Lew's message was uncalled for and just showed your ignorance and 
unwillingness to learn.

Lars Enderin wrote:
> opero citato (op cit)
>     
> Definition
> 
> Reference term used usually in a footnote to refer to the title of a 
> work cited in a previous footnote. Latin for, in the work cited.
> 
> I think Lew did not use it correctly, but no matter. Your response to 
> Lew's message was uncalled for and just showed your ignorance and 
> unwillingness to learn.

I had cited the work before.

-- 
Lew

I see people have been randomly taking my name in vain here again.

What, you thought I wouldn't google every couple of weeks to see if
you weren't spreading this shit back to cljp?

On Nov 5, 2:32=A0pm, Lars Enderin <lars.hole...@telia.com> wrote:
> Harold Yarmouth wrote:
>
> [some refined variant of Twisted's [implied insult deleted]]

No. None of the nasty things that you have said or implied about me
are at all true.

> Each posting from "Harold Yarmouth" makes me more confident that
> "Harold" is the same person who uses/has used the aliases Twisted

Oh, boy, here we go again. Somebody's gone and retooled the paranoia
factory, resuming production.

Now I'll be off to see my stockbroker regarding a possible purchase of
psychiatry futures. I foresee a bubble in that area in the near
future...

My name is not Harold.

On Nov 6, 11:25=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Lars Enderin wrote:
> > Harold Yarmouth wrote:
> > [some refined variant of Twisted's [implied insult deleted]]

No. None of the nasty things that you have said or implied about me
are at all true.

> > Each posting from "Harold Yarmouth" makes me more confident that
> > "Harold" is the same person who uses/has used the aliases Twisted

Oh, boy, somebody's started up the paranoia factory again.

My name is not Harold.

> That seems to be the logical conclusion.

No, it does not.

On Nov 8, 10:25=A0am, Lars Enderin <lars.ende...@telia.com> wrote:
> Harold Yarmouth wrote:
> > Besides, the text gave every indication (at least to one that doesn't
> > know Latin) that the URL might be that of a Latin-language Web page. I
> > don't read Latin so going there would have been pointless.
>
> strengthens my conviction that you are indeed Twisted.

No, he is not.

> From http://www.businessdictionary.com/definition/opero-citato-op-cit.htm=
l:
>
> opero citato (op cit)
>
> Definition
>
> Reference term used usually in a footnote to refer to the title of a
> work cited in a previous footnote.

You'll be damned lucky if anything you write ever ends up even
aspiring to the status of "footnote", Lars-hole.

> I think Lew did not use it correctly

That's hardly a surprise, given my prior experience with him. He was a
flaming arsehole and know-nothing know-it-all then and I strongly
suspect that he's a flaming arsehole and know-nothing know-it-all now.
*quickly browses rest of thread* Yep, he is, and now he's gone off on
some other poor sap. And unfortunately he, and you, have apparently
decided for some crazy reason to drag me into the middle of your
little spat with Harold. I can't imagine why, given how things turned
out the last time you picked a fight with me. Two of your clique lost
net access and another got a stern warning from the university whose
network he was abusing to post off-topic and inflammatory nastiness to
cljp, and all of you wound up covered in mud while none of it stuck to
me. Meanwhile the newsgroup's SNR suffered for several full months. Do
you really want a repeat of that, Lars-hole? Because you know, this
time, what the outcome will be. I will prevail through steely resolve
and a steadfast refusal to knuckle under, with a little help from
being on the side of truth and justice, and you will dig yourselves
into the deepest fucking hole you ever did see. In fact, since you
never climbed fully out of the last one you dug, you'll probably wind
up in China. (And that would be the end of your unfettered use of the
net -- if libel and slander aren't already blocked by the Great
Firewall, I'm sure it could be arranged through my international
business contacts and their lobbying clout with various diplomats and
trade representatives.)

> [some humdrum insults of Harold deleted]

History and my own reading of the thread suggest that, whatever Harold
may be (I don't know him), Lew is in fact an arrogant twit with a
penchant for picking fights in the intertubes. (And I DO know *him*.)

The ScuzzBuster wrote:

> What, you thought I wouldn't google every couple of weeks to see if
> you weren't spreading this shit back to cljp?

Well, we did have some (alas, vain) hope that the new meds would 
address some of the symptoms.

The ScuzzBuster wrote:
> On Nov 8, 10:25 am, Lars Enderin <lars.ende...@telia.com> wrote:
  > You'll be damned lucky if anything you write ever ends up even
> aspiring to the status of "footnote", Lars-hole.

What's your point?

> *quickly browses rest of thread* Yep, he is, and now he's gone off on
> some other poor sap. And unfortunately he, and you, have apparently
> decided for some crazy reason to drag me into the middle of your
> little spat with Harold. I can't imagine why, given how things turned
> out the last time you picked a fight with me. Two of your clique lost
> net access and another got a stern warning from the university whose
> network he was abusing to post off-topic and inflammatory nastiness to
> cljp, and all of you wound up covered in mud while none of it stuck to
> me. Meanwhile the newsgroup's SNR suffered for several full months. Do
You're dreaming. Maybe the SNR of this group suffered, but that was 
because of your obsessive insistence on denying that you could ever be 
wrong. Nobody got burned but you.
> you really want a repeat of that, Lars-hole? Because you know, this
> time, what the outcome will be. I will prevail through steely resolve
> and a steadfast refusal to knuckle under, with a little help from
> being on the side of truth and justice, and you will dig yourselves
You live in a world of your own. No contact with reality.
> into the deepest fucking hole you ever did see. In fact, since you
> never climbed fully out of the last one you dug, you'll probably wind
> up in China. (And that would be the end of your unfettered use of the
> net -- if libel and slander aren't already blocked by the Great
> Firewall, I'm sure it could be arranged through my international
> business contacts and their lobbying clout with various diplomats and
> trade representatives.)
What are you on? You are hallucinating.

Mike Schilling wrote:
> Joshua Cranmer wrote:
>> I don't know any Latin; I don't even know what `op. cit.' means
> 
> It's like left and right.  Or black and white.  They're op. cits.

Oh for God's sake! Am I the only person here who actually got a passing 
grade in high-school English?
-- 
John W. Kennedy
  If Bill Gates believes in "intelligent design", why can't he apply it 
to Windows?

John W Kennedy wrote:
> Mike Schilling wrote:
>> Joshua Cranmer wrote:
>>> I don't know any Latin; I don't even know what `op. cit.' means
>>
>> It's like left and right.  Or black and white.  They're op. cits.
> 
> Oh for God's sake! Am I the only person here who actually got a passing 
> grade in high-school English?

Give the guy a break - it was a worthy pun.

-- 
Lew

On Nov 8, 3:49=A0pm, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:
> The ScuzzBuster wrote:
> > What, you thought I wouldn't google every couple of weeks to see if
> > you weren't spreading this shit back to cljp?
>
> [insult deleted]

No, you're the crazy one.

None of the nasty things that you have said or implied about me are at
all true.

On Nov 8, 4:11=A0pm, Lars Enderin <lars.hole...@telia.com> wrote:
[snip]

NO! DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

> The ScuzzBuster wrote:
> > You'll be damned lucky if anything you write ever ends up even
> > aspiring to the status of "footnote", Lars-hole.
>
> What's your point?

Isn't that obvious? My point was that you should shut the hell up.

> > *quickly browses rest of thread* Yep, he is, and now he's gone off on
> > some other poor sap. And unfortunately he, and you, have apparently
> > decided for some crazy reason to drag me into the middle of your
> > little spat with Harold. I can't imagine why, given how things turned
> > out the last time you picked a fight with me. Two of your clique lost
> > net access and another got a stern warning from the university whose
> > network he was abusing to post off-topic and inflammatory nastiness to
> > cljp, and all of you wound up covered in mud while none of it stuck to
> > me. Meanwhile the newsgroup's SNR suffered for several full months. Do
>
> [insult deleted] Maybe the SNR of this group suffered, but that was
> because of [false accusations deleted]

You're the crazy one and you're a liar.

None of the nasty things that you have said or implied about me are at
all true.

> [mangled quoted material deleted]

Learn to quote properly!

> > I will prevail through steely resolve and a steadfast refusal to
> > knuckle under, with a little help from being on the side of truth
> > and justice, and you will dig yourselves
>
> [insult deleted]

No, you're the crazy one.

None of the nasty things that you have said or implied about me are at
all true.

> [mangled quoted material deleted]

Learn to quote properly!

> > (And that would be the end of your unfettered use of the net --
> > if libel and slander aren't already blocked by the Great Firewall,
> > I'm sure it could be arranged through my international business
> > contacts and their lobbying clout with various diplomats and trade
> > representatives.)
>
> [insults deleted]

No, you're the drug abuser and the crazy one.

None of the nasty things that you have said or implied about me are at
all true.

The ScuzzBuster wrote:
> On Nov 8, 4:11 pm, Lars Enderin <lars.hole...@telia.com> wrote:
> [snip]
> 
> NO! DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

Was it not you who said: "I don't take orders from you?"
<http://groups.google.com/group/comp.lang.java.programmer/msg/eacbe771ac092524>

So if you won't take orders from us, why should Mr. Enderin take orders 
from you?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> The ScuzzBuster wrote:
>> On Nov 8, 4:11 pm, Lars Enderin <lars.hole...@telia.com> wrote:
>> [snip]
>>
>> NO! DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

Thanks to Joshua for showing me this.  I'm LMAO.

> Was it not you who said: "I don't take orders from you?"
> <http://groups.google.com/group/comp.lang.java.programmer/msg/eacbe771ac092524> 
> 
> So if you won't take orders from us, why should Mr. Enderin take orders 
> from you?

Especially when ScuzzMonkey is so rude to Lars, calling him names and such.

-- 
Lew

The ScuzzBuster wrote:
> On Nov 8, 4:11 pm, Lars Enderin <lars.hole...@telia.com> wrote:
> [snip]
> 
> NO! DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

You have tried that many times before.

Did it work ?

What did Einstein say about that ?

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Tom Anderson wrote:
>>> On Sun, 2 Nov 2008, Arne Vajh�j wrote:
>>>> Harold Yarmouth wrote:
>>>>> Arne Vajh�j wrote:
>>>>>> 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?
>>>>
>>>> For "the most lame argument posted to cljp in 2008".
>>>
>>> Can trolls even be nominated for that?
>>
>> Ooops.
>>
>> No.
>>
>> Rule number 5 explicit prohibits giving the award to a troll.
>>
>> Sorry about that.
> 
> Are we here to discuss Java or medieval Germanic fairy-tale monsters 
> that don't really exist?

http://en.wikipedia.org/wiki/Troll_(Internet)

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> 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.
>>
>> There are 9 no-arg getInstance methods among those 44
> 
> I also never said I meant "only in the core Java API". I meant "in Java 
> code in general", as in ALL of it.

But the Java API is *the* example of how SUN think Java should be used.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> You mean that you don't know any examples and that you just made up your
>> claim and you don't have the character to admit it
> 
> No, I do not. I mean that I know of too many to list

Just post the first 25 that come s to your mind ...

Arne

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> But it is already proven that your rule is not followed in the
>> Java API and you have not been able to mention any library that
>> does.
> 
> I mentioned that an awful lot of them do,

English is not my native language, but even me knows that
"mention that an awful lot of them do" does not qualify as
"mention any".

>                                            and I'll thank you to stop a) 
> accusing me of being a liar and b) lying about me!

Well - you just agreed with me (see above).

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> 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.
>>
>> There is nothing pre-industrial about those.
> 
> Sure there is. The country in which the industrial revolution began used 
> the Gregorian calendar, and as a result it more or less got standardized 
> on. That same country spoke English, and as a result English also more 
> or less got standardized on.

Believe it or not but the IT world has not standardized on English
for business apps.

It is a very common requirements to support French, German, Spanish
and worse the East Asian languages.

> You wouldn't recommend that String support translation into different 
> languages, would you?

No.

But that is rather irrelevant since this is not what Calendar supplies.

> Likewise, conversion of the internal representation of time to and from 
> a particular localized representation belongs in the periphery of the 
> program, and the support classes to do so should be clearly distinct 
> from the core classes that are merely used to work with 
> network/file/internal time representations, compare these for equality 
> and order, and perform duration arithmetic upon them.

That is what Date does. This is not what Calendar does.

> See that JSR a link to which somebody else posted. It gets this more or 
> less exactly right, unlike you. You therefore might find it quite 
> educational.

I think you should read it.

They want to change a lot of things. But none of them are related
to your misunderstandings of the Calendar class.

And they indeed want to support other calendars than Gregorian.

>> And internationalization of business apps are very common.
> 
> Of their user interface layers, yes. (Imagine the chaos that would ensue 
> if the back-end DB had some dates in different time zones, some in the 
> Julian calendar, and so forth. This isn't done, which further reinforces 
> my point.)

Which of course is completely irrelevant.

The fact that Calendar's are not used in DAL or database does not change
the fact that Calendars are used in business apps.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> BTW, it is worth mentioning that the .NET framework includes
>> several calendars:
>>
>> EastAsianLunisolarCalendar
>> GregorianCalendar
>> HebrewCalendar
>> HijriCalendar
>> JapaneseCalendar
>> JapaneseLunisolarCalendar
>> JulianCalendar
>> KoreanCalendar
>> KoreanLunisolarCalendar
>> PersianCalendar
>> TaiwanCalendar
>> TaiwanLunisolarCalendar
>> ThaiBuddhistCalendar
>> UmAlQuraCalendar
>>
>> They know how important i18n is for business apps.
> 
> It is. And it belongs in the UI layer. Times should be something simple, 
> like nanoseconds since the epoch, under the hood.

Which it also is in Java - the Date class.

But Java need something to match that with calendars - and it has.

Oh - and it is not just PL - it is also BLL.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> John W Kennedy wrote:
>>> 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.
>>
>> Believing that non Gregorian calendars are older and most suited
>> for religious purposes is either ignorant or racists.
> 
> No, it is not. It is simply an observation of a statistically-true fact.

Please give a link to that statistic.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Java enables people to write programs.
>>
>> Java need to support multiple calendars to support people that
>> use those calendars.
> 
> And it can do so in a UI-oriented class. DateFormat might be expanded to 
> provide such functionality. Or a CalendarFormat class added.

You have completely misunderstood the purpose of Calendar.

It is not a formatting/parsing class.

It is a class that applies the rules of the calendar.

>> Java should not limit functionality due to Taleban religious
>> beliefs or racists that think only the Gregorian Calendar
>> is needed.
> 
> It is not racist to think that only the Gregorian calendar is needed. It 
> is simple pragmatism: only the Gregorian calendar is ordinarily *used*. 
> It covers the vast majority of programming needs, since it's a defacto 
> international standard throughout the developed world and throughout 
> international commerce.

You are telling people that computer programs should use your
calendar and not their own.

That was the way of colonialism was done 300 years ago.

It is not how globalization work.

> Furthermore, we were discussing the core business-logic classes. Those 
> should use a single time standard, ideally, say a Gregorian calendar 
> with the UTC+0000 time-zone. Alternative ways of displaying dates to the 
> user and of parsing dates from the user belong in a separate utility class.

No. That about "core business-logic classes" is just something you
brought into the discussion late.

And BTW it is not even correct. Some types of business logic requires
Calendar knowledge.

> Note also that never have I suggested, though you keep insinuating 
> otherwise, that such users should not be able to use alternative 
> calendars. I just questioned including them in core Java, and especially 
> involving them in the core Date class and its builder object rather than 
> putting them somewhere more peripheral.

They are not in Date - they are in Calendar.

And Calendar is not a Date builder.

So wrong twice.

Arne

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>>                                            It is exceptionally rude 
>>> and uncalled-for behavior that I shall not tolerate from you or 
>>> anybody else!
>>
>> Well - you don't have anything to say in that matter.
> 
> Oh, yes, I do. I just DID say something, didn't I?

"anything to say in that matter" does not mean "say something".

Arne

Harold Yarmouth wrote:
> Arne Vajhøj wrote:
>> Harold Yarmouth wrote:
>>> Arne Vajhøj wrote:
>>>> 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?
>>
>> For "the most lame argument posted to cljp in 2008".
> 
> Oh, no matter. I wouldn't have won that one anyway.

You would have gotten a lot of votes.

Unfortunately for you then you got disqualified
due to the troll rule.

Arne

Arne Vajhøj wrote:
> No. That about "core business-logic classes" is just something you
> brought into the discussion late.
> 
> And BTW it is not even correct. Some types of business logic requires
> Calendar knowledge.

Case in point: I'm on the programming staff of a multi-million-dollar Java EE 
project involving electronic documents (XML, among other things) sent to a 
central location from all over the world.  java.util.Calendar is essential to 
that project to coordinate the various time zones involved, including business 
rules as to due dates, intervals between document submissions and the like.

Calendar is most assuredly a core business-logic class for that project.

Early in the project some less-experienced programmers attempted to express 
these types of business rules without using Calendar.  That code has caused 
all kinds of difficulty in production.  I've been rewriting some of that logic 
using Calendar, and this has demonstrably simplified the task of getting it right.

-- 
Lew

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> But it is already proven that your rule is not followed in the
>>> Java API and you have not been able to mention any library that
>>> does.
>>
>> I mentioned that an awful lot of them do,
> 
> English is not my native language, but even me knows that
> "mention that an awful lot of them do" does not qualify as
> "mention any".
> 
>>                                            and I'll thank you to stop 
>> a) accusing me of being a liar and b) lying about me!
> 
> Well - you just agreed with me (see above).

It is not a rule that no-argument getInstance() return a singleton.  It is not 
valid that because many such methods return a singleton that all such must do 
so.  That's like saying that because some cars are built to move at 200 miles 
per hour that all cars must do so, or that because some cars are built to run 
on batteries that all must do so, or that because some people have blond hair, 
all must do so.  This is a well-recognized logical fallacy, the notion that 
because things sometimes happen a certain way they must always do so.

In the particular case of the Java API and getInstance(), Arne has already 
proven that "Harold" is wrong:
> I just grepped the Java API docs. There are nine no-arg getInstance
> methods. Of those zero are singletons.

That is statistical evidence, and conclusive.

If the gods of Java don't follow the rule, and in their writing (as cited 
upthread) allow for APIs not to follow any such rule, then we mere mortals 
must not impute such a superstition.

-- 
Lew

Harold Yarmouth wrote:
>> Are we here to discuss Java or medieval Germanic fairy-tale monsters 
>> that don't really exist?

Arne Vajhøj wrote:
> http://en.wikipedia.org/wiki/Troll_(Internet)

We already know that "Harold Yarmouth" doesn't really exist.

-- 
Lew

On Nov 8, 8:29=A0pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
[snip]

NO. DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

> The ScuzzBuster wrote:
> > On Nov 8, 4:11 pm, Lars Enderin <lars.hole...@telia.com> wrote:
[snip]

NO FEEDBACK LOOPS!

> Was it not you who said: "I don't take orders from you?"

Turnabout is fair play, arsehole.

> So if you won't take orders from us, why should Mr. Enderin take orders
> from you?

It's called "giving him a taste of his own medicine".

On Nov 8, 9:25=A0pm, Lew <no...@lewscanon.com> wrote:
[snip]

NO. DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

> Joshua Cranmer wrote:
[snip]

NO FEEDBACK LOOPS!

> Thanks to Joshua for showing me this. [implied insult deleted]

No. None of the nasty things that you have said or implied about me
are at all true.

> > Was it not you who said: "I don't take orders from you?"

Turnabout is fair play.

> > So if you won't take orders from us, why should Mr. Enderin take orders
> > from you?

It's called "giving him a taste of his own medicine".

> Especially when [insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

> is so rude to Lars, calling him names and such.

Turnabout is fair play.

I put up with constant abuse and namecalling from Lars for *years*
before deciding to treat him like the piece of gutter trash he
apparently is.

*Years*.

I have the patience of a saint.

Don't you dare sit in judgment of me, not until you've walked a mile
(and at least two years) in my shoes.

On Nov 8, 10:44=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
[snip]

NO. DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

> The ScuzzBuster wrote:
> > On Nov 8, 4:11 pm, Lars Enderin <lars.hole...@telia.com> wrote:
[snip]

NO FEEDBACK LOOPS!

> > NO! DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.
>
> [implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

reckoning54@gmail.com wrote:
> On Nov 8, 8:29 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> [snip]
> 
> NO. DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

Did that type of giving order succeed last time you tried ?

Arne

On Nov 9, 12:26=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
[snip]

NO. DO NOT POST WHILE I AM STILL CATCHING UP. WAIT 24 HOURS FIRST.

> reckonin...@gmail.com wrote:
> > On Nov 8, 8:29 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
[snip]

NO FEEDBACK LOOPS!

> [implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

reckoning54@gmail.com wrote:
> NO FEEDBACK LOOPS!

Without feedback loops--negative feedback loops, in fact--you'd die. 
Your body has several negative feedback loops intended to prevent 
escalation of certain disorders.

So why are feedback loops so bad?

"Science. It works, bitches."

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> Arne Vajh�j wrote:
>> Harold Yarmouth wrote:
>>> Arne Vajh�j wrote:
>>>> Harold Yarmouth wrote:
>>>>> Arne Vajh�j wrote:
>>>>>> Harold Yarmouth wrote:
>>>>>>> Arne Vajh�j wrote:
>>>>>>>> Harold Yarmouth wrote:
> 
> Tiny request... could we start trimming replies?

Tiny request... could we start trimming all non-Java-related subject matter?

Arne Vajh�j misquoted me:
> Harold Yarmouth did not write:
>> Arne Vajh�j misquoted me:
>>> Harold Yarmouth did not write:
>>>> Arne Vajh�j misquoted me:
>>>>> 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.
>>>> Yes, it is.
>>>
>>> Glad you agree with me.
>>
>> I do not!
> 
> Yes usually mean agree.

But, as I said in the previous post (and you dishonestly trimmed out and 
otherwise ignored!), that is a complete misquotation of what I wrote.

This is what was actually originally written:

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

As you can CLEARLY see, I was agreeing that you had forgotten to check
your confrontational attitude at the door, not agreeing with any of your
vicious and uncalled-for personal attacks.

Now stop the dishonest quoting and other extremely childish tricks and 
start discussing Java, or else go away. Your behavior is completely 
inappropriate for this forum, not to mention totally uncalled-for, and 
it will not be tolerated.

> You forget something. People laugh at you - they are not afraid of you.

No, Arne, people laugh at *you*. They laugh at your combination of 
thuggish attitude, poor grammar, childish dishonest cheap tricks to try 
to "win" an argument, and complete inability to back up your blustery 
words with any credible threat of real force.

It's like being hissed and growled at by a tiny little kitten, one that 
frequently tries to hide to pounce at your leg when you walk by, only 
its tail is sticking out into plain view. Everybody sees through its 
pathetic attempts at deception and sneakiness, and nobody perceives a 
real threat, no matter how furiously hissy it gets.

And it can't communicate in clear, understandable English like an adult 
human being.

The same is true of you being nasty online, where you have no ability to 
project force, your attempts at dishonesty are easily repudiated by a 
quick Google Groups search, and you apparently can't make even a fairly 
short post without at least three typos that make you look like you're 
barely out of the single-digit grades in school. "Yes usually mean 
agree" is one step up from "I can has cheezburger?" and two hundred 
steps down from the its/it's mistakes that, as near as I can tell, even 
the average Ph.D. doesn't seem to be able to avoid.

You are laughable, Arne.

I should probably stop wasting my time replying to your crap, but it's 
amusing seeing you flail about in your ignorance and blind anger, and it 
also causes you to further destroy your own credibility by posting 
nonsense like you just did, thereby neutralizing what little threat you 
pose here, that of possibly convincing other people to believe your crap.

Nobody will, now, when they see the cheap tricks you tried to use to 
make it look like I was agreeing with you when I wasn't. That kind of 
transparent desperation ploy is the last refuge of a stupid and angry 
man that realizes he's about to lose the argument. (One that's obviously 
nowhere near smart enough to realize that he already HAD lost the argument.)

>>>> I am an experienced programmer
>>>
>>> Sorry - nobody will believe that.
>>
>> Is that intended as a threat?
> 
> Obviously not. I was just noting a fact.

But it is not a fact. You seem to think you can control others' opinions 
of me, but you can't. You can maybe control others' opinions of *you*. 
So far, you're doing a bang-up job, between your poor communication 
skills and transparently dishonest tactics. Perhaps you should quit 
while ... well, normally I'd say "quit while you're ahead", but you're 
not ahead, you're way way behind. But you should still quit; like the 
gambler that's lost his car, you shouldn't keep going until you lose 
your house, and then your shirt. Not when you're clearly outclassed* and 
Lady Luck clearly is not on your side.

* You, of course, would be outclassed by a ten year old with no 
debate-team training or anything, and by any smarter-enough-than-average 
five year old.

> Well - please sue. I guess it would be possible to find around
> 5000 witnesses from here that can testify that your ability to
> read documentation and understanding of OOP are exceptional low.

No, the only things they'll testify are "exceptional low" are
a) your honesty,
b) your intelligence (did you REALLY think nobody would see
    through your creative quoting tricks?), and
c) your English reading comprehension and writing grade level

(Really I should stop and "pick on someone my own size". This is like 
being in a fistfight with a grade school bully. Except that the grade 
school bully was dumb enough to walk up to and punch *me*, so I wasn't 
picking on anyone -- he was and he bit off more than he could chew!)

>>> You don't read documentation.
>>
>> I do.
> 
> Nonsense. If you had, then this thread would not have existed.

Yet I did, and this thread nonetheless exists.

Clearly, you have made a mistake in your logic somewhere.

See if you can figure out, on your own, where the mistake is.

Hint: If the conclusion is false, either the premise is false or the 
conclusion does not follow from the premise. Figure out first which of 
these (if not both) is the case, and then continue from there.

>>> You don't understand object oriented principles.
>>
>> I do.
> 
> No.

Yes, I do.

> Your idea of having Calendar implement Gregorian calendar
> and have other calendars overwrite methods

My idea was of having Calendar implement a basic Date factory 
functionality and have non-standard calendars provide Date- or Calendar- 
wrapping and translation functionality, actually. Though given what I 
now know regarding your apparent grade-level, I shouldn't expect you to 
be able to comprehend any of that.

In other words, Date, Calendar (or maybe another name would be better), 
and LocalizedCalendar (or maybe just Calendar, if the date-factory got a 
different name), analogously to the existing pattern of String, 
StringBuilder, and Collator, MessageBundle, and the other peripheral 
classes for localized String handling.

>>>>> You do not let Calendar be GregorianCalendar and then ask all
>>>>> other Calendars to overwrite most methods.
>>>>
>>>> Who said anything about that?
>>>
>>> You did.
>>
>> No, I said that the object charged with the responsibility of being 
>> the no-frills Date builder should be simple and straightforward, and 
>> need not be polymorphic (and thus should not, given the simplicity 
>> requirement).
> 
> Not true.

Well, now you've descended to calling me a liar and otherwise being at 
the lowly "did too! did not!" level of argumentation.

There's really no point in my continuing this. It's like participating 
in a gunfight with an unarmed opponent. It's not really fair to Arne if 
I continue.

But then again, he was the one who started the fight ...

>>> you do not even know about the "is a" principle.
>>
>> A lie.
> 
> Obviously not.

Obviously yes.

>> It's just that it's not relevant to the issue of how to implement a 
>> simple Date builder,
> 
> What Date builder ?
> 
> As explained to you many times then Calendar is not a Date builder.

I don't need anything explained to me. I know Calendar has other 
functions. The problem is that it IS also the Date builder -- as 
evidenced by the Date constructors that produce specific dates and times 
being deprecated with a note in the docs to use Calendar instead.

Calendar's split responsibilities are the cause of many if not all of 
its woes. The date-building functionality and the localization 
functionality belong in separate places, and even at separate layers.

>> Calendars for use in ordinary business-programming situations are not. 
>> Anything else belongs outside the core date/time classes. Same way 
>> String does not have the functionality of Collator or MessageBundle 
>> built-in, nor does StringBuilder.
> 
> Surprisingly calendar functionality belongs in the calendar classes.

Then it is date-builder functionality that does not.

It is probably best to use the name Calendar for the 
localization/translation classes. But then the mutable-Date class used 
to just construct a Date from a given bunch of integers should be broken 
out as a separate class and named, oh, say, DateBuilder, and those Date 
javadocs I mentioned updated to point people to DateBuilder.

Arne Vajh�j wrote:
> Lars Enderin wrote:
>> Harold Yarmouth wrote:
>> [some refined variant of Twisted's usual rants]
>>
>> Each posting from "Harold Yarmouth" makes me more confident that 
>> "Harold" is the same person who uses/has used the aliases Twisted, 
>> Scuzzbuster, Twerpinator, zerg, etc.
> 
> That seems to be the logical conclusion.

That's two wrong conclusions you've reached lately. As I said the 
previous time, this means that either a premise was wrong or the 
conclusion did not actually follow from the premises.

I will give you an additional hint: in both of your recent errors, the 
same cause occurred. In other words, either a premise was faulty in both 
cases or the conclusion did not logically follow from the premise in 
both cases.

I leave it as a challenge to you to figure out which, to then figure out 
what your error actually was in each case, and to then learn from those 
two errors.

Arne Vajh�j wrote:
>> Yes. They mixed "just get me a stock Date for this day, month, and 
>> year" functionality and "do all these whiz-bang locale-dependent 
>> presentations and manipulations" functionality in one place.
> 
> The Calendar has very well-defined functionality in having all the
> calendar specific manipulations of Date.

The problem is that it ALSO has very well-defined functionality for 
building fresh Dates from components. It's as if they'd jam-packed all 
of the functionality of both StringBuilder and Collator, or 
StringBuilder and MessageBundle, into a single class. It would have been 
a horrid mess -- as the Calendar class actually proved to be, as has 
been noted by "Lew", Mark, Roedy, and one or two other people here as 
well. In fact you are about the only person here that's still arguing 
the increasingly-untenable position that "Calendar is perfect as it is 
and anyone suggesting otherwise is an idiot".

>  >> Try read the documentation of the Calendar class again.
>  >
>  > Try read Emily fucking Post again! Your rudeness is becoming incredibly
>  > tiresome. Learn to be polite in public!
> 
> You will never become a programmer

This is ridiculous. I already AM a programmer, and I probably was a 
programmer when you were still in diapers. (Particularly if you ARE 
still in diapers.)

I have written, over the course of my career so far, in the neighborhood 
of 10,000,000 lines of code. Some individual programs or systems have 
over 10,000 lines of code of mine in them (or did at one point; parts 
may of course have been rewritten or modified since). I've everything 
from video game code to web browser and web spider code and code for 
business apps under my belt. Applets, database front-ends for specific 
report generation, game graphics engines (circa 1980 mind you), game 
logic and AI (more recently), network tools (very recently), and more, 
much of it in Java. You probably personally have, use at work, or 
otherwise have contact with code that I wrote, without even knowing it 
since most software does not have a movie-style list of credits on it 
and though the newer games do the ones I worked on never made it to the 
big-time.

You, on the other hand, have a level of proficiency with language and 
communications that implies a grade level in the mid-to-upper single 
digits, and the attitude of a schoolyard bully, which gives me the 
strong suspicion that your greatest contribution to computer programming 
thus far has probably been to write 10. PRINT "HELLO WORLD" 20. GOTO 10 
and somehow thereby manage to crash the school's computer, earning an F 
in sixth-grade computer class. (Assuming they still teach BASIC or Logo 
programming at your school, that is, and not just pointing and clicking 
and other user-oriented stuff. Sadly, I think most schools don't expose 
everyone to simple programming at a young age anymore.)

>  >> programmers that does not read the documentation produce lousy code.
>  >
>  > My code is not lousy.
> 
> But it was.

No, it was not.

You're in no fit state to judge, seeing as a) you have not seen it and 
b) you wouldn't know good code if you got to see an example of some in
    your fifth-grade computer class tomorrow morning.

> You did not read the docs

I did read the docs.

> your code did not work

My code is working fine, after I dealt with the serious oddity of Dates 
generated identically not comparing .equals(). An oddity that could 
easily catch anybody by surprise when they first had occasion to work 
with Dates much in Java, and that stems from what pretty much everyone 
but you has agreed is a design flaw in Date/Calendar.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>> My IDE shows me the documentation for the method whose invocation 
>>>> I'm writing. That would be the set method in this case.
>>>
>>> Your mistake !
>>
>> No. If there is any mistake there, it was made by the IDE's 
>> developers, and I was not involved.
> 
> Again you completely missed the point.

No, I have not. You have.

> You should read the docs outside of your IDE.

So sez you. But you do not decide such things.

Even if that were true, it does not make the fact that the IDE shows me 
the documentation for the method whose invocation I'm writing a mistake 
that I made. If the IDE's behavior is a mistake, it is a mistake made by 
someone who worked as a developer on that IDE. And since I have not ever 
been a developer of that IDE, that person cannot be me.

> And I can really not see any point in contacting NetBeans
> team and ask them to get a guy named Paul to fire his web
> browser and read the Java docs.

Neither can I. What does some guy named Paul have to do with any of 
this, anyway? I don't see the relevance. You seem to have pulled that 
hypothetical example of a possible future course of action for you 
completely out of a hat.

I suppose it's some sort of surrealism or absurdism or something, 
perhaps an attempt at humor. "Attempt" being the operative word here.

Oh, ok, I confess I cracked a smile at the image of some guy telling 
Internet Explorer "you're fired!" and launching the Opera installer he'd 
just used it to download. Or maybe something more elaborate? With 
apologies to Swiffer:

*guy behind desk in office, facing a chair whose back is to the camera 
and whose back conceals anyone who might be in it; desk has a computer 
monitor on it*

"You're slow, you're bloated, you often fall asleep on the job, and you 
keep letting in the wrong people. I can't have you working the desk here 
anymore. I'm going to have to let you go."

*clickety-click*

*reverse angle shows IE icon being dropped on Recycle Bin icon on 
computer screen on desk, and no fat donut-eating rent-a-cop, or anyone 
else, sitting in the facing chair in the office*

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> I also never said I meant "only in the core Java API". I meant "in 
>> Java code in general", as in ALL of it.
> 
> But the Java API is *the* example of how SUN think Java should be used.

It is *the* example of how Sun themselves use Java. It is *an* example 
of *one way* Sun think Java should be used.

Actually, I'm not even sure about the latter. A lot of Sun's own code 
violates a lot of best practises. Consider this gem from the Javadoc for 
javax.swing.JComboBox:


actionPerformed

public void actionPerformed(ActionEvent e)

     This method is public as an implementation side effect. do not call 
or override.

     Specified by:
         actionPerformed in interface ActionListener


Sun evidently has far more trouble with the concept of encapsulation (or 
perhaps that of private inner classes) than anyone you should be 
recommending I emulate. :-)

There is a lot of code out there that is much, much better than some of 
Sun's code.

Arne Vajh�j wrote:
>> Sure there is. The country in which the industrial revolution began 
>> used the Gregorian calendar, and as a result it more or less got 
>> standardized on. That same country spoke English, and as a result 
>> English also more or less got standardized on.
> 
> Believe it or not but the IT world has not standardized on English
> for business apps.

I never said that it did. I said that it's a language most businessmen 
in the world that deal at the multinational level know and frequently 
use. International commerce also tends to use the Gregorian Calendar 
(and various time zones) almost exclusively.

> It is a very common requirements to support French, German, Spanish
> and worse the East Asian languages.

That is not relevant. It is not a very common requirement to support 
non-Gregorian calendars, except for software with an ethnically-narrow 
target market (and usually esoteric purposes). I don't see non-Gregorian 
calendars being used in business applications like payroll processing 
and the like, except for custom software for a business in a non-Western 
country.

>> You wouldn't recommend that String support translation into different 
>> languages, would you?
> 
> No.

Okay. Argument over, then.

>> Likewise, conversion of the internal representation of time to and 
>> from a particular localized representation belongs in the periphery of 
>> the program, and the support classes to do so should be clearly 
>> distinct from the core classes that are merely used to work with 
>> network/file/internal time representations, compare these for equality 
>> and order, and perform duration arithmetic upon them.
> 
> That is what Date does. This is not what Calendar does.

Not quite. If that were the case, Date would have non-deprecated 
constructors to "just get me a date from these integers", or a 
DateBuilder class analogous to StringBuilder in its role, or both. I see 
neither.

"Just get me a date from these integers" is a basic function that should 
exist, should assume a Gregorian calendar, and should have two versions, 
one that takes a Locale and uses its time zone and one that uses the 
time zone for the current default locale.

That function should be available from an 
otherwise-nonlocalization-specific class, as StringBuilder's 
functionality can be found outside of MessageBundle and Collator.

Since that apparently excludes Calendar, it seems it belongs in Date 
itself or in a class that's different from either, yet I don't find it 
there.

>> See that JSR a link to which somebody else posted. It gets this more 
>> or less exactly right, unlike you. You therefore might find it quite 
>> educational.
> 
> I think you should read it.

I already HAVE read it. Didn't I imply as much above?

> They want to change a lot of things. But none of them are related
> to your misunderstandings

That is because I HAVE NO MISUNDERSTANDINGS.

Please stop gratuitously and publicly insulting me. It has become 
abundantly clear that you are the one with *ahem* "problems" here. I 
should think that you would not wish to call too much attention to those 
problems.

> And they indeed want to support other calendars than Gregorian.

In peripheral classes that can be avoided when you just want to do 
something simple.

They believe much more strongly in the KISS principle than you 
apparently do. (Or rather, to be more specific, the "keep the core 
simple, stupid" principle.)

>> Of their user interface layers, yes. (Imagine the chaos that would 
>> ensue if the back-end DB had some dates in different time zones, some 
>> in the Julian calendar, and so forth. This isn't done, which further 
>> reinforces my point.)
> 
> Which of course is completely irrelevant.

No. YOU are completely irrelevant.

You clearly have nothing to say that's really about Java. Everything you 
write is really not about Java at all, but rather it's about me. And I 
am not within this newsgroup's topic bounds, so discussing me here is 
off-charter. Please stop.

> The fact that Calendar's are not used in DAL or database does not change
> the fact that Calendars are used in business apps.

In the outer layers with the other I18N/L10N stuff. And, unfortunately, 
deeper inside when what they really need is a DateBuilder, but only 
because of the Date/Calendar system's flaws and Calendar's schizophrenic 
nature.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Harold Yarmouth wrote:
>>>>                                            It is exceptionally rude 
>>>> and uncalled-for behavior that I shall not tolerate from you or 
>>>> anybody else!
>>>
>>> Well - you don't have anything to say in that matter.
>>
>> Oh, yes, I do. I just DID say something, didn't I?
> 
> "anything to say in that matter" does ... mean "say something".

Umm-hmm.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Joshua Cranmer wrote:
>>> Harold Yarmouth wrote:
>>>> Lew wrote elsewhere in this same thread:
>>>>> evidence that 'getX' factories don't necessarily imply singletons. 
>>>>> When the gods speak, mortals should listen.
>>>>
>>>> I'll take that as a "yes".
>>>
>>> Missing in that quote is the fact that you took out a line.
>>
>> A line that could not be interpreted without knowing Latin, and that 
>> therefore is irrelevant to the matter of *how that paragraph would be 
>> perceived by some guy reading it*.
> 
> It is relevant

It is irrelevant. This is an English-language newsgroup. Latin is 
off-topic here.

And so are your insults, which I took the liberty of trimming as such. 
Your opinions of me have nothing to do with Java programming and 
therefore DO NOT BELONG IN THIS NEWSGROUP.

Got it?

John W Kennedy wrote:
> Harold Yarmouth wrote:
>> I don't know any Latin; I don't even know what <some latin
>> abbreviation> means
> 
> Oh for God's sake! Am I the only person here who actually got a passing 
> grade in high-school English?

Most high school curricula do not cover Latin, least of all in an 
English course. I am surprised to hear that apparently a high school 
exists that does so, rather than placing it where it obviously belongs, 
either in its own class or in History And Geography.

(Fixed up attributions. Somehow my words were being attributed to Joshua 
Cranmer instead of to me.)

Lars Enderin wrote:
> Harold Yarmouth wrote:
>> Besides, the text gave every indication (at least to one that doesn't 
>> know Latin) that the URL might be that of a Latin-language Web page. I 
>> don't read Latin so going there would have been pointless.
>>
> I use Thunderbird, like you do.

I don't see how that is relevant to the language of some remote Web 
page. Even were Thunderbird to have some miraculous natural-language 
translation power, Thunderbird does not display Web pages for me. Opera 
does.

> even if you were not educated enough

I grow tired of this insulting, snobbish, and superior attitude.

There is ABSOLUTELY NOTHING WRONG with not having an education IN LATIN. 
NOBODY much has an education in Latin anymore. There are respected 
Ph.D.s that know less Latin than I do. In fact, beyond knowing specific 
Latin-derived terminology for some scientific field or similarly, 
knowledge of Latin is almost useless. Nowadays, knowing the language 
itself, and not just a vocabulary laced with borrowings into English 
from Latin, is basically only important if you're a historian with an 
interest in Europe in Roman times.

> background material is symptomatic and strengthens my conviction that 
> you are indeed Twisted.

I am not. All the conviction in the world on your part won't make any 
difference to that, either.

> Latin for, in the work cited.

How fascinating. However, your assumption that everyone should know this 
little bit of the Latin language is still clearly incorrect.

> I think Lew did not use it correctly

If so, then it is even more unreasonable for you to berate me for not 
knowing exactly what the hell he meant by it!

> Your response to Lew's message was uncalled for

My response to Lew's message was perfectly appropriate when someone had 
just blathered a bunch of insults and off-topic silliness, accusing me 
of not paying attention, and then ended with "when the gods speak, 
mortals should listen".

Since then, Lew has more explicitly compared himself to a god at least 
twice.

> and just showed your ignorance and unwillingness to learn.

If not knowing much Latin qualifies me for the label "ignorant" then 
fine, I'm ignorant. So sue me.

If not being interested in learning Latin qualifies me for the label 
"unwilling to learn", then fine, I'm unwilling to learn -- or at least, 
unwilling to learn random and mostly-useless-or-obsolete things that are 
difficult to learn* on the say-so of some random asshole on the Internet 
that threatens to flame me (oooh, I'm scared!) if I don't do as he says.

*Languages, in general, being difficult for adults to learn, and Latin 
reputed to be particularly so, though not as bad as the so-called tone 
languages from the far east.

Lew wrote:
> Lars Enderin wrote:
>> opero citato (op cit)
>>     Definition
>>
>> Reference term used usually in a footnote to refer to the title of a 
>> work cited in a previous footnote. Latin for, in the work cited.
>>
>> I think Lew did not use it correctly, but no matter. Your response to 
>> Lew's message was uncalled for and just showed your ignorance and 
>> unwillingness to learn.
> 
> I had cited the work before.

Readers of these posts may refer to my response to Arne's post regarding 
my supposed "ignorance and unwillingness to learn"; apparently anyone 
that does not know Latin is ignorant and anyone who does not go learn it 
immediately upon encountering a fragment of Latin in some random, 
pointless, and off-topic Usenet post displays "unwillingness to learn".

Personally, I'd instead call both of them symptoms of "unwillingness to 
waste one's time on difficult, obsolete, and 
uninteresting-to-one-personally subject matter", and also of "having a 
birth date after circa 1500 CE" and "not being a Catholic priest", but 
what the hey.

On Nov 9, 9:07=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> reckonin...@gmail.com wrote:
> > NO FEEDBACK LOOPS!
>
> Without feedback loops--negative feedback loops, in fact--you'd die.
> Your body has several negative feedback loops intended to prevent
> escalation of certain disorders.

Those are not the particular feedback loops that I object to.

Arne Vajhøj wrote:
>>> Another good example of where you completely misses the point.
>>
>> NO. I do not,
> 
> It has been clearly demonstrated that you missed that Lew was
> referring to Joshua

What has been clearly demonstrated is that I don't know beans about 
Latin. That is a very different thing from "missing the point", and it 
is also not any kind of crime, failing, or justification for your hostility.

Furthermore, none of this seems to have anything to do with Java, so I 
respectfully suggest that this is not the appropriate forum for 
continuing this. Not that I see much point in your continuing this.

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> It has to include the milliseconds because it has to convert
>>> to and from Date which contains milliseconds.
>>
>> Why? It could conceivably instead just be precise to the nearest 
>> second, with conversion from Date losing (usually useless) information 
>> and conversion to Date filling those in with zeros.
> 
> That would make the milliseconds part of Date rather useless.

Not given that there are other ways to get a Date. Anyway, the real 
issue is why the most-precise "set" method doesn't either set the 
milliseconds to a caller-specified value or else set them to zero or 
some other such predetermined value. I cannot see any real use for being 
able to say "change this time from Tue Oct. 27 2003, 4:17:11 and change 
to the exact same number of milliseconds after Thurs Oct. 29 2003 
8:11:49" and the like.

>> It should either do so, or provide a seven-argument set method, or the 
>> sixth argument set method should zero out the milliseconds. One of 
>> those three.
> 
> What about providing a set method that can set milliseconds ?

Not good enough. A method should exist such that someone can completely 
determine the output with just one method call. Your proposal would not 
satisfy that requirement.

Harold Yarmouth wrote:
> Arne Vajh�j wrote:
>>>> Another good example of where you completely misses the point.
>>>
>>> NO. I do not,
>>
>> It has been clearly demonstrated that you missed that Lew was
>> referring to Joshua
>
> What has been clearly demonstrated is that I don't know beans about
> Latin.

Yarmouth delenda est. 

Harold Yarmouth wrote:
> Lew wrote:
>> Lars Enderin wrote:
>>> opero citato (op cit)
>>>     Definition
>>>
>>> Reference term used usually in a footnote to refer to the title of a 
>>> work cited in a previous footnote. Latin for, in the work cited.
>>>
>>> I think Lew did not use it correctly, but no matter. Your response to 
>>> Lew's message was uncalled for and just showed your ignorance and 
>>> unwillingness to learn.
>>
>> I had cited the work before.
> 
> Readers of these posts may refer to my response to Arne's post regarding 
> my supposed "ignorance and unwillingness to learn"; apparently anyone 
> that does not know Latin is ignorant and anyone who does not go learn it 
> immediately upon encountering a fragment of Latin in some random, 
> pointless, and off-topic Usenet post displays "unwillingness to learn".
> 
> Personally, I'd instead call both of them symptoms of "unwillingness to 
> waste one's time on difficult, obsolete, and 
> uninteresting-to-one-personally subject matter", and also of "having a 
> birth date after circa 1500 CE" and "not being a Catholic priest", but 
> what the hey.

Understanding a Latin abbreviation often used in scientific works was 
not essential to interpreting Lew's posting that referred to a Java 
"god". You only needed to click on a simple link (URL). Instead, you 
keep making wrong assumptions and accusations.
Typical Twisted behaviour.

Harold Yarmouth wrote:
> John W Kennedy wrote:
>> Joshua Cranmer wrote:
>>> I don't know any Latin; I don't even know what <some latin
>>> abbreviation> means
>>
>> Oh for God's sake! Am I the only person here who actually got a 
>> passing grade in high-school English?
> 
> Most high school curricula do not cover Latin, least of all in an 
> English course. I am surprised to hear that apparently a high school 
> exists that does so, rather than placing it where it obviously belongs, 
> either in its own class or in History And Geography.

Do you know what `Homo sapiens' is? The short word `circa' (often 
abbreviate as `c.')? `et cetera' (etc.)? A lot of writing uses 
abbreviations of Latin words or phrases. Any basic technical writing 
course should cover these.

> (Fixed up attributions. Somehow my words were being attributed to Joshua 
> Cranmer instead of to me.)

Actually, those were my very own words. You dirty thief. ;-)

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

bbound@gmail.com wrote:
> On Nov 9, 9:07 am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>> reckonin...@gmail.com wrote:
>>> NO FEEDBACK LOOPS!
>> Without feedback loops--negative feedback loops, in fact--you'd die.
>> Your body has several negative feedback loops intended to prevent
>> escalation of certain disorders.
> 
> Those are not the particular feedback loops that I object to.

Damn it.  I wish I hadn't wiped out my old kill file.

Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de stultis nil nisi 
malum. Stultus est sicut stultus facit, as my momma used to say.

-- 
Lew

Lew wrote:
> bbound@gmail.com wrote:
>> On Nov 9, 9:07 am, Joshua Cranmer <Pidgeo...@verizon.invalid> 
>> wrote:
>>> reckonin...@gmail.com wrote:
>>>> NO FEEDBACK LOOPS!
>>> Without feedback loops--negative feedback loops, in fact--you'd 
>>> die.
>>> Your body has several negative feedback loops intended to prevent
>>> escalation of certain disorders.
>>
>> Those are not the particular feedback loops that I object to.
>
> Damn it.  I wish I hadn't wiped out my old kill file.
>
> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de 
> stultis
> nil nisi malum. Stultus est sicut stultus facit, as my momma used to
> say.

My mom used to say "facit" too, though not in front of company. 

In comp.lang.java.programmer message <gf8g3l$ta5$1@aioe.org>, Mon, 10
Nov 2008 00:16:57, Harold Yarmouth <hyarmouth991476@hotmail.com> posted:
>
>Most high school curricula do not cover Latin, least of all in an
>English course. I am surprised to hear that apparently a high school
>exists that does so, rather than placing it where it obviously belongs,
>either in its own class or in History And Geography.

What experience do you have of anything outside the USA and possibly
Canada?

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Web  <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

Joshua Cranmer wrote:
> Harold Yarmouth wrote:
>> John W Kennedy wrote:
>>> Joshua Cranmer wrote:
>>>> I don't know any Latin; I don't even know what <some latin
>>>> abbreviation> means
>>>
>>> Oh for God's sake! Am I the only person here who actually got a 
>>> passing grade in high-school English?
>>
>> Most high school curricula do not cover Latin, least of all in an 
>> English course. I am surprised to hear that apparently a high school 
>> exists that does so, rather than placing it where it obviously 
>> belongs, either in its own class or in History And Geography.
> 
> Do you know what `Homo sapiens' is? The short word `circa' (often 
> abbreviate as `c.')? `et cetera' (etc.)? A lot of writing uses 
> abbreviations of Latin words or phrases. Any basic technical writing 
> course should cover these.

I still can't believe that he graduated high school without learning how 
to do attributions. Unless, perhaps, he was in the "future unskilled 
laborer" group. (Hmmm.... That /would/ explain why he's so touchy about 
anything suggesting that his intellectual attainments are less than 
complete.)
-- 
John W. Kennedy
  "When a man contemplates forcing his own convictions down another 
man's throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
   -- Joy Davidman, "Smoke on the Mountain"

Mike Schilling wrote:
> Lew wrote:
>> bbound@gmail.com wrote:
>>> On Nov 9, 9:07 am, Joshua Cranmer <Pidgeo...@verizon.invalid> 
>>> wrote:
>>>> reckonin...@gmail.com wrote:
>>>>> NO FEEDBACK LOOPS!
>>>> Without feedback loops--negative feedback loops, in fact--you'd 
>>>> die.
>>>> Your body has several negative feedback loops intended to prevent
>>>> escalation of certain disorders.
>>> Those are not the particular feedback loops that I object to.
>> Damn it.  I wish I hadn't wiped out my old kill file.
>>
>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de 
>> stultis
>> nil nisi malum. Stultus est sicut stultus facit, as my momma used to
>> say.
> 
> My mom used to say "facit" too, though not in front of company. 

And the horse it rode in on?

-- 
John W. Kennedy
  If Bill Gates believes in "intelligent design", why can't he apply it 
to Windows?

Arne Vajhøj wrote:
> Harold Yarmouth wrote:
>> Arne Vajhøj wrote:
>>> Harold Yarmouth wrote:
>>>> Arne Vajhøj wrote:
>>>>> You will not get nominated twice !
>>>>
>>>> Excuse me?
>>>
>>> For "the most lame argument posted to cljp in 2008".
>>
>> Oh, no matter. I wouldn't have won that one anyway.
> 
> You would have gotten a lot of votes.

 From you stuffing the ballot box.

You are completely wrong about me, though. And you are wrong to keep 
posting large volumes of non-Java-related crap to this newsgroup. Please 
stop it. It can serve no useful purpose.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Are we here to discuss Java or medieval Germanic fairy-tale monsters 
>> that don't really exist?
> 
> http://en.wikipedia.org/wiki/Troll_(Internet)

A quick skim of that article reveals that it does not have anything 
whatsoever to do with Java.

You are posting to the wrong newsgroup.

A quick search of the groups available at my server shows 
alt.just.trolling and alt.rec.trolling as two likely more-appropriate 
newsgroups for your posts. There's also an alt.troll.

I respectfully suggest that your non-Java-related posts might be better 
off posted to one of those newsgroups, not to comp.lang.java.programmer, 
and that your Java-related posts remain here but be entirely and solely 
about Java.

"Lew" wrote:
> We already know that "Harold Yarmouth" doesn't really exist.

If I don't exist, then why am I apparently writing a news post even as 
we speak?

Lew wrote:
>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de stultis
>>> nil nisi malum. Stultus est sicut stultus facit, as my momma used to
>>> say.

Mike Schilling wrote:
>> My mom used to say "facit" too, though not in front of company. 

John W Kennedy wrote:
> And the horse it rode in on?

Mike, you obviously studied Classical Latin, not just (or instead of?) Church 
Latin.  My high-school Latin teacher would've been proud of you.

-- 
Lew

Lew wrote:
> Lew wrote:
>>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de stultis
>>>> nil nisi malum. Stultus est sicut stultus facit, as my momma used to
>>>> say.
> 
> Mike Schilling wrote:
>>> My mom used to say "facit" too, though not in front of company. 
> 
> John W Kennedy wrote:
>> And the horse it rode in on?
> 
> Mike, you obviously studied Classical Latin, not just (or instead of?) 
> Church Latin.  My high-school Latin teacher would've been proud of you.

There is an old saying that everyone should learn one of the four
classic languages: Greek, Latin, Fortran and Cobol.

Well - I know Fortran.

:-)

Arne

Lew wrote:
> Lew wrote:
>>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de
>>>> stultis nil nisi malum. Stultus est sicut stultus facit, as my
>>>> momma used to say.
>
> Mike Schilling wrote:
>>> My mom used to say "facit" too, though not in front of company.
>
> John W Kennedy wrote:
>> And the horse it rode in on?
>
> Mike, you obviously studied Classical Latin, not just (or instead
> of?) Church Latin.  My high-school Latin teacher would've been proud
> of you.

I did, though I'm not sure how a collection of bad puns displays that. 
One of my (public) high school's English teachers was a classicist, 
and she had permission to teach latin as long as she could fill the 
classes.  I expect Latin ended there when she retired.  My son's now 
taking Latin, though that's more natural, since his high school is run 
by Jesuits. 

Arne Vajh�j wrote:
> "mention that an awful lot of them do" does not qualify as
> "mention any".

That's ridiculous. You might as well have just claimed that 10 < 1.

What happened, the number of them exceeded your brain's 
Integer.MAX_VALUE and wrapped around to become negative?

>>                                            and I'll thank you to stop 
>> a) accusing me of being a liar and b) lying about me!
> 
> Well - you just agreed with me (see above).

I did not.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> Arne Vajh�j wrote:
>>> Java need to support multiple calendars to support people that
>>> use those calendars.
>>
>> And it can do so in a UI-oriented class. DateFormat might be expanded 
>> to provide such functionality. Or a CalendarFormat class added.
> 
> You have completely misunderstood the purpose of Calendar.

No, I have not. And you must stop publicly insulting me and publicly 
lying about me now.

I have understood that Calendar is being used for two distinct purposes, 
one of which is Locale-dependent in some way that goes beyond time 
zones, and one of which is not.

Those uses should be separated into two different classes.

We are now basically quibbling over which of those to call Calendar and 
which to call something else.

A pointless quibble if you ask me. Actually I'd favor keeping Calendar 
similar to as-is and creating DateBuilder for basic Date-construction 
jobs that don't need to care about any localization (except perhaps for 
time zone matters).

> It is not a formatting/parsing class.

I never claimed it was.

> It is a class that applies the rules of the calendar.

Collator is a class that applies locale-dependent rules for Strings, but 
you don't see Collator doing double-duty as StringBuilder.

>> It is not racist to think that only the Gregorian calendar is needed. 
>> It is simple pragmatism: only the Gregorian calendar is ordinarily 
>> *used*. It covers the vast majority of programming needs, since it's a 
>> defacto international standard throughout the developed world and 
>> throughout international commerce.
> 
> You are telling people that computer programs should use your
> calendar and not their own.

No! I am not! I am saying that the CORE of the LANGUAGE does not need to 
support other than a sensible, widely-used default in this case -- more 
peripheral classes or third-party ones can provide the other functionality.

I think that you are INTENTIONALLY misrepresenting what I've said as an 
argument in favor of forbidding non-Gregorian calendar code ever to be 
written in Java. It is not. I have never said as much. I have only 
debated what should or should not be part of the core set of utility 
classes.

I don't know why you keep misrepresenting me. I guess you're trying to 
discredit what I say, for whatever reason. The stupid thing is, anyone 
can go back to read what I actually wrote and see that you're lying your 
ass off, so I don't understand why you bother to even try. It's 
pointless and idiotic, and only a moron won't see right through you. 
Same deal as with your deliberate misquotations earlier.

Please give it up. You are not really arguing about anything to do with 
Java anymore, not as part of an honest debate and a quest for greater 
understanding of Java anyway. You are just being boorish and rude out of 
some sort of grudge or personal axe to grind. This is not the 
appropriate venue for such behavior. Take it elsewhere.

>> Furthermore, we were discussing the core business-logic classes. Those 
>> should use a single time standard, ideally, say a Gregorian calendar 
>> with the UTC+0000 time-zone. Alternative ways of displaying dates to 
>> the user and of parsing dates from the user belong in a separate 
>> utility class.
> 
> No.

Yes.

> And BTW it is not even correct.

Yes it is.

> Some types of business logic requires Calendar knowledge.

I use "business logic" to refer to the core operations only, not 
whatever goes on peripherally to translate them into a user-visible 
interface and to translate the user's input back in. Calendar basically 
gives locale-dependent names to things like "23885436548839 milliseconds 
since the epoch" and translates such back, including dates and 
locale-dependent intervals and "next foobar after bazquux" type 
constructs. This sort of thing is generally in the next outermost layer 
of an application below the Swing/AWT using layer, along with 
MessageBundle and Collator usage and lots of other Locale-related code. 
Layers deeper than those top two generally shouldn't mess with Locale 
save perhaps to keep track of an app-wide locale setting, store it 
somewhere, and restore it.

>> Note also that never have I suggested, though you keep insinuating 
>> otherwise, that such users should not be able to use alternative 
>> calendars. I just questioned including them in core Java, and 
>> especially involving them in the core Date class and its builder 
>> object rather than putting them somewhere more peripheral.
> 
> They are not in Date - they are in Calendar.

I said "in the core Date class and its builder object"; the latter is, 
at present, Calendar.

> And Calendar is not a Date builder.

Yes it is. It is not SOLELY a Date builder, but it is a Date builder. 
Read Date's constructors' Javadocs if you don't believe me. Most of them 
are deprecated with a note pointing to Calendar. Ergo, Date construction 
is generally done via Calendar instead of directly. Ergo, Calendar 
functions as a Date builder.

> So wrong twice.

NO. YOU ARE THE ONE WHO IS WRONG HERE, AND YOU ARE WRONG BECAUSE YOU 
KEEP INTENTIONALLY MISREADING MY WORDS.

I SUGGEST A SIMPLE SOLUTION FOR THAT: STOP READING MY WORDS AT ALL. 
SINCE YOU ARE APPARENTLY INCAPABLE OF REASON OR OF CIVILITY, AT LEAST 
WHENEVER ADDRESSING ME, YOU SHOULD KILLFILE ME OR OTHERWISE IGNORE ME 
STARTING IMMEDIATELY.

Lew wrote:
> Arne Vajhøj wrote:
>> No. That about "core business-logic classes" is just something you
>> brought into the discussion late.
>>
>> And BTW it is not even correct. Some types of business logic requires
>> Calendar knowledge.

No, YOU are not even correct. I don't consider Calendar manipulations 
(other than just Date building) to be "business logic" any more than I 
consider using Collator to sort something on its way to being displayed 
in the UI to be "business logic". It's part of the interface layer. The 
business logic only knows from "milliseconds since the epoch" and, 
perhaps, the translations of same into Gregorian dates in (preferably) 
UTC+0000.

> Case in point: I'm on the programming staff of a multi-million-dollar 
> Java EE project involving electronic documents (XML, among other things) 
> sent to a central location from all over the world.  java.util.Calendar 
> is essential to that project to coordinate the various time zones 
> involved, including business rules as to due dates, intervals between 
> document submissions and the like.

That is not a "case in point". Locale-specific rules may be involved in 
providing the localized user interfaces, including selection of which 
business rules to apply, but in the core logic classes I *hope* your 
Dates are all represented in one particular time base and that when the 
chosen business rules say "x is three days after y" it just adds 
3*86400*1000ms to some number somewhere under the hood.

If a Locale determines whether that parameter is "three" or "five" or 
some other number, that doesn't matter. It's still (I hope!) happening 
in a layer not far beneath the UI layer.

Because if you've got mixed time-zones (or worse) in the core data 
representations you've got big trouble on the way.

> Calendar is most assuredly a core business-logic class for that project.

No. See above.

Arne Vajh�j wrote:
> Harold Yarmouth wrote:
>> It is. And it belongs in the UI layer. Times should be something 
>> simple, like nanoseconds since the epoch, under the hood.
> 
> Which it also is in Java - the Date class.
> 
> But Java need something to match that with calendars - and it has.

There's a problem with this, though -- those deprecated Date 
constructors. How is someone supposed to get a Date from, say, numbers 
extracted from a time stamp in some text file in a natural way? 
Calendar.getInstance(), set(yy, mm, dd, h, m, s), getTime() runs into 
the problem that started this whole mess, and involves Calendar. Where 
is the simple, easy to use DateBuilder that does not have these problems?

And why are you so dead set against the idea that adding one would be a 
good idea?

> Oh - and it is not just PL - it is also BLL.

No. See an earlier post.

Arne Vajh�j wrote:
> Please give a link to that statistic.

Google is your friend.

(If you want me to do your research for you, it'll be $50 an hour plus 
expenses.)

Arne Vajh�j wrote:
> "mention that an awful lot of them do" does not qualify as
> "mention any".

That's ridiculous. You might as well have just claimed that 10 < 1.

What happened, anyway -- the number of them exceeded your brain's
Integer.MAX_VALUE and wrapped around to become negative?

>>                                            and I'll thank you to stop 
>> a) accusing me of being a liar and b) lying about me!
> 
> Well - you just agreed with me (see above).

I did not.

"Lew" wrote:
> Arne Vajhøj wrote:
>> "mention that an awful lot of them do" does not qualify as
>> "mention any".

Sure it does. 10 (an awful lot) > 1 (at least one).

>> Well - you just agreed with me (see above).

I did not.

> It is not a rule that no-argument getInstance() return a singleton.

I never claimed otherwise.

I said a no-argument getInstance(), *in the absence of the functionality 
having a clear requirement for a polymorphic implementation*, *tends 
often* to indicate a *per-thread, singleton, cached, or otherwise 
not-always-new instance*.

That is a substantially different statement and I will thank BOTH of you 
to stop misquoting me and misrepresenting what I am saying.

I keep saying "X usually indicates one of A, B, or C" and you keep 
posting "Harold is an idiot, he keeps saying that X indicates A!" when 
that simply is not true.

At this point, I have to consider that any future similar assertions 
about what I'm supposedly saying, from either of you, will constitute 
intentional lying rather than just you being mistaken yet again. Since 
you have been told, not once but several times, what my claim really is, 
I can't believe that any more instances of your attributing the wrong 
claim to me will be accidental. They will be deliberate, if of course 
they occur at all. And deliberately incorrect = lying.

> It is not valid that because many such methods return a singleton that
> all such must do so.

Then it is quite fortunate that that is not my claim. See above.

> In the particular case of the Java API and getInstance(), Arne has 
> already proven that "Harold" is wrong

No, he has not. And this incorrect and insulting assertion followed 
quite a volume of condescending priggishness that I trimmed.

What the HELL is the matter with you?

Please go away. The original problem that started this thread is long 
since solved. In fact I'd solved it before even posting this thread, 
which I did only to point out how stupid the current API is in this 
particular area.

There is no reason to continue this.
* That Date and Calendar have problems is not in serious dispute -- most
   people here, except you and Arne, agree with me.
* That, specifically, Calendar.newInstance(), calendar.set(maximum
   specificity), calendar.getTime() produces a non-deterministic output
   is a flaw is not in serious dispute -- most people here, except you
   and Arne, agree with me.
* Your negative opinions of me clearly ARE in serious dispute. At the
   same time, however, they have no bearing on anything to do with
   Java and this is therefore the wrong newsgroup for discussing the
   matter any further.

Since the above three things are what seem to be in contention in this 
thread, and since only you two dispute the first two items and the third 
is off-topic here, there is no reason whatsoever for this thread to 
continue in cljp and plenty of reasons for it not to.

I suggest that you let the first two issues drop and if you have some 
more insults you really need to get out of your system you send them to 
me by email. Just don't be surprised if I delete them without replying.

>> There are nine no-arg getInstance methods. Of those zero are
>> singletons.
> 
> That is statistical evidence, and conclusive.

Nonsense. The sample size is ridiculously small. Far too small to make 
any inference and call it "conclusive", and I'd say too small to really 
call it "evidence". It is "statistical", and that's about it.

> If the gods of Java

Enough with the gods shit! There are no gods. Period. Show me putative 
empirical evidence for a god, and I will show you empirical evidence for 
either noise or some mechanistically-understandable phenomenon. Though I 
can't tell you yet which of those two it will be, not in advance of 
seeing the evidence in question.

Arne Vajh�j wrote:
> Nigel Wade wrote:
>> You're wasting your time arguing with this idiot. [rest of insults
>> and paranoia trimmed to save bandwidth]

I am not an idiot. My IQ was 137 last time I had it measured.

> I noted it.

That's because YOU are an idiot.

>> It would be prudent to add this new identity to the same kill-file.

I am not a "new identity", I am forty-seven years old which makes me a 
"middle-aged identity".

> He will show up with yet another identity next month.

No, I will show up as Harold Yarmouth and that's it.

Harold Yarmouth wrote:
> Sure it does. 10 (an awful lot) > 1 (at least one).

This is what Arne wants: one, specific example. Saying that an awful lot 
of countries support terrorism doesn't mean that they do; it provides no 
more support for the statement that there exists a country that supports 
terrorism than it does for the statement that many countries have budget 
deficits.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

In article <UjaSk.4515$hc1.4248@flpi150.ffdc.sbc.com>,
 "Mike Schilling" <mscottschilling@hotmail.com> wrote:

> Lew wrote:
> > Lew wrote:
> >>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de
> >>>> stultis nil nisi malum. Stultus est sicut stultus facit, as my
> >>>> momma used to say.
> >
> > Mike Schilling wrote:
> >>> My mom used to say "facit" too, though not in front of company.
> >
> > John W Kennedy wrote:
> >> And the horse it rode in on?
> >
> > Mike, you obviously studied Classical Latin, not just (or instead 
> > of?) Church Latin.  My high-school Latin teacher would've been 
> > proud of you.
> 
> I did, though I'm not sure how a collection of bad puns displays 
> that. One of my (public) high school's English teachers was a 
> classicist, and she had permission to teach latin as long as she 
> could fill the classes.  I expect Latin ended there when she retired. 
> My son's now taking Latin, though that's more natural, since his high 
> school is run by Jesuits. 

Traditionally, there are four ways to pronounce Latin: classical, 
ecclesiastical, Jesuit and wrong.

-- 
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/

John B. Matthews wrote:
> In article <UjaSk.4515$hc1.4248@flpi150.ffdc.sbc.com>,
>  "Mike Schilling" <mscottschilling@hotmail.com> wrote:
>> Lew wrote:
>>> Lew wrote:
>>>>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de
>>>>>> stultis nil nisi malum. Stultus est sicut stultus facit, as my
>>>>>> momma used to say.
>>> Mike Schilling wrote:
>>>>> My mom used to say "facit" too, though not in front of company.
>>> John W Kennedy wrote:
>>>> And the horse it rode in on?
>>> Mike, you obviously studied Classical Latin, not just (or instead 
>>> of?) Church Latin.  My high-school Latin teacher would've been 
>>> proud of you.
>> I did, though I'm not sure how a collection of bad puns displays 
>> that. One of my (public) high school's English teachers was a 
>> classicist, and she had permission to teach latin as long as she 
>> could fill the classes.  I expect Latin ended there when she retired. 
>> My son's now taking Latin, though that's more natural, since his high 
>> school is run by Jesuits. 
> 
> Traditionally, there are four ways to pronounce Latin: classical, 
> ecclesiastical, Jesuit and wrong.

And the last is probably the most common ...

:-)

Arne

Lew wrote:
>> Mike, you obviously studied Classical Latin, not just (or instead
>> of?) Church Latin.  My high-school Latin teacher would've been proud
>> of you.

Mike Schilling wrote:
> I did, though I'm not sure how a collection of bad puns displays that. 

Because no one would fear saying "fotchit" in public.

-- 
Lew

In article <49199474$0$90271$14726298@news.sunsite.dk>,
 Arne Vajh�j <arne@vajhoej.dk> wrote:

> John B. Matthews wrote:
> > In article <UjaSk.4515$hc1.4248@flpi150.ffdc.sbc.com>,
> >  "Mike Schilling" <mscottschilling@hotmail.com> wrote:
> >> Lew wrote:
> >>> Lew wrote:
> >>>>>> Re-plonked.  De mortuis nil nisi bonum.  Ok, in this case, de
> >>>>>> stultis nil nisi malum. Stultus est sicut stultus facit, as my
> >>>>>> momma used to say.
> >>> Mike Schilling wrote:
> >>>>> My mom used to say "facit" too, though not in front of company.
> >>> John W Kennedy wrote:
> >>>> And the horse it rode in on?
> >>> Mike, you obviously studied Classical Latin, not just (or instead 
> >>> of?) Church Latin.  My high-school Latin teacher would've been 
> >>> proud of you.
> >> I did, though I'm not sure how a collection of bad puns displays 
> >> that. One of my (public) high school's English teachers was a 
> >> classicist, and she had permission to teach latin as long as she 
> >> could fill the classes.  I expect Latin ended there when she 
> >> retired. My son's now taking Latin, though that's more natural, 
> >> since his high school is run by Jesuits. 
> > 
> > Traditionally, there are four ways to pronounce Latin: classical, 
> > ecclesiastical, Jesuit and wrong.
> 
> And the last is probably the most common ...

Indeed, the student's still lament:

  Latin is a dead language. It never changes, you see.
  First, it killed the Romans, and now it's killing me.

Of course, we're joking. In _The Everything Learning Latin Book_, teh 
preface lists 10 good reasons to study Latin:

<http://books.google.com/books?isbn=1580628818>

I still get a kick out of Catullus.

Ob Java: An experimental JulianCalendar class is described here:

<http://jscience.org/experimental/javadoc/org/jscience/history/calendars/
JulianCalendar.html>

Today is III idus novem MMDCCLXI ab urbe condita [the third day 
(inclusive) before the ides (13th) of the ninth month in the 2,761st 
year from the founding of the city].

-- 
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/

Dr J R Stockton wrote:
> In comp.lang.java.programmer message <gf8g3l$ta5$1@aioe.org>, Mon, 10
> Nov 2008 00:16:57, Harold Yarmouth <hyarmouth991476@hotmail.com> posted:
>> Most high school curricula do not cover Latin, least of all in an
>> English course. I am surprised to hear that apparently a high school
>> exists that does so, rather than placing it where it obviously belongs,
>> either in its own class or in History And Geography.
> 
> What experience do you have of anything outside the USA and possibly
> Canada?

Latin per se doesn't matter. He should have learned "op. cit." in 
English class, under the general heading of "how to write research 
papers with proper footnotes". Unless, perhaps (as I say elsewhere), he 
was enrolled in the American equivalent of -- forgive me, I don't recall 
the proper term -- put on track to leave school after the fifth form.
-- 
John W. Kennedy
  "You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
   -- C. S. Lewis.  "An Experiment in Criticism"

On Nov 10, 5:20=A0am, Lars Enderin <lars.hole...@telia.com> wrote:
> Harold Yarmouth wrote:
> > Personally, I'd instead call both of them symptoms of "unwillingness to
> > waste one's time on difficult, obsolete, and
> > uninteresting-to-one-personally subject matter", and also of "having a
> > birth date after circa 1500 CE" and "not being a Catholic priest", but
> > what the hey.
>
> You only needed to click on a simple link (URL). Instead, you
> [insults deleted, insulting both Harold and myself]

None of the nasty things that you have said or implied about me are at
all true.

On Nov 10, 8:55=A0am, Lew <no...@lewscanon.com> wrote:
> bbo...@gmail.com wrote:
> > On Nov 9, 9:07 am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> >> reckonin...@gmail.com wrote:
> >>> NO FEEDBACK LOOPS!
> >> Without feedback loops--negative feedback loops, in fact--you'd die.
> >> Your body has several negative feedback loops intended to prevent
> >> escalation of certain disorders.
>
> > Those are not the particular feedback loops that I object to.
>
> Damn it. =A0[implied insult deleted]
>
> [implied insult deleted]. =A0De mortuis [rest of suspected insult
> deleted], as my momma used to say.

No. None of the nasty things that you have said or implied about me
are at all true.

On Nov 10, 11:54=A0am, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:
> Lew wrote:
> > Damn it. =A0[implied insult deleted]
>
> > [implied insult deleted]. =A0De mortuis [rest of suspected
> > insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> My mom used to say "facit" too, though not in front of company.

And precisely what, pray tell, does this have to do with Java?

On Nov 10, 4:50=A0pm, John W Kennedy <jwke...@attglobal.net> wrote:
> Mike Schilling wrote:
> > Lew wrote:
> >> Damn it. [implied insult deleted]
>
> >> [implied insult deleted].=A0De mortuis [rest of suspected
> >> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> > My mom used to say "facit" too, though not in front of company.
>
> And the horse it rode in on?

And what, precisely, does any of this have to do with Java?

On Nov 10, 10:20=A0pm, Lew <no...@lewscanon.com> wrote:
> Lew wrote:
> >>> [implied insult deleted]. =A0De mortuis [rest of suspected
> >>> insult deleted], as my momma used to say.

None of the nasty things that you have said or implied about me are at
all true.

> >> My mom used to say "facit" too, though not in front of company.
> > And the horse it rode in on?
> Mike, you obviously studied Classical Latin, not just (or instead of?) Ch=
urch
> Latin. =A0My high-school Latin teacher would've been proud of you.

None of this seems to have anything whatsoever to do with Java
programmer.

On Nov 10, 10:30=A0pm, Arne Vajh=F8j <arse@vajhoej.dk> wrote:
> Lew wrote:
> > Lew wrote:
> >>>> [implied insult deleted].=A0De mortuis [rest of suspected
> >>>> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> >>> My mom used to say "facit" too, though not in front of company.
> >> And the horse it rode in on?
> > Mike, you obviously studied Classical Latin, not just (or instead of?)
> > Church Latin. =A0My high-school Latin teacher would've been proud of yo=
u.
> There is an old saying that everyone should learn one of the four
> classic languages: Greek, Latin, Fortran and Cobol.

I don't see how any of this long-winded discussion is at all relevant
to the topic of Java programming. Least of all the mentions of Fortran
(yuck) and Cobol (bletcherous!).

On Nov 11, 2:17=A0am, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:
> Lew wrote:
> > Lew wrote:
> >>>> [implied insult deleted].=A0De mortuis [rest of suspected
> >>>> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> >>> My mom used to say "facit" too, though not in front of company.
> >> And the horse it rode in on?
> > Mike, you obviously studied Classical Latin, not just (or instead
> > of?) Church Latin. =A0My high-school Latin teacher would've been proud
> > of you.
> I did, though I'm not sure how a collection of bad puns displays that.
> One of my (public) high school's English teachers was a classicist,
> and she had permission to teach latin as long as she could fill the
> classes. =A0I expect Latin ended there when she retired. =A0My son's now
> taking Latin, though that's more natural, since his high school is run
> by Jesuits.

None of this has anything whatsoever to do with Java.

On Nov 11, 8:27=A0am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <UjaSk.4515$hc1.4...@flpi150.ffdc.sbc.com>,
> =A0"Mike Schilling" <mscottschill...@hotmail.com> wrote:
> > Lew wrote:
> > > Lew wrote:
> > >>>> [implied insult deleted].=A0De mortuis [rest of suspected
> > >>>> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> > >>> My mom used to say "facit" too, though not in front of company.
> > >> And the horse it rode in on?
> > > Mike, you obviously studied Classical Latin, not just (or instead
> > > of?) Church Latin. =A0My high-school Latin teacher would've been
> > > proud of you.
> > I did, though I'm not sure how a collection of bad puns displays
> > that. One of my (public) high school's English teachers was a
> > classicist, and she had permission to teach latin as long as she
> > could fill the classes. =A0I expect Latin ended there when she retired.
> > My son's now taking Latin, though that's more natural, since his high
> > school is run by Jesuits.
> Traditionally, there are four ways to pronounce Latin: classical,
> ecclesiastical, Jesuit and wrong.

The only way for Latin to be on topic here is in a discussion of
Java's Collator class.

Lew's insulting of me is, of course, not on topic here at all.

On Nov 11, 9:19=A0am, Arne Vajh=F8j <arse@vajhoej.dk> wrote:
> John B. Matthews wrote:
> > In article <UjaSk.4515$hc1.4...@flpi150.ffdc.sbc.com>,
> > =A0"Mike Schilling" <mscottschill...@hotmail.com> wrote:
> >> Lew wrote:
> >>> Lew wrote:
> >>>>>> [implied insult deleted].=A0De mortuis [rest of suspected
> >>>>>> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> >>>>> My mom used to say "facit" too, though not in front of company.
> >>>> And the horse it rode in on?
> >>> Mike, you obviously studied Classical Latin, not just (or instead
> >>> of?) Church Latin. =A0My high-school Latin teacher would've been
> >>> proud of you.
> >> I did, though I'm not sure how a collection of bad puns displays
> >> that. One of my (public) high school's English teachers was a
> >> classicist, and she had permission to teach latin as long as she
> >> could fill the classes. =A0I expect Latin ended there when she retired=
..
> >> My son's now taking Latin, though that's more natural, since his high
> >> school is run by Jesuits.
> > Traditionally, there are four ways to pronounce Latin: classical,
> > ecclesiastical, Jesuit and wrong.
> And the last is probably the most common ...

Unfortunately, so are off-topic, pointless, and inflammatory news
posts in comp.lang.java.programmer.

On Nov 11, 12:05=A0pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <49199474$0$90271$14726...@news.sunsite.dk>,
> =A0Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> > John B. Matthews wrote:
> > > In article <UjaSk.4515$hc1.4...@flpi150.ffdc.sbc.com>,
> > > =A0"Mike Schilling" <mscottschill...@hotmail.com> wrote:
> > >> Lew wrote:
> > >>> Lew wrote:
> > >>>>>> [implied insult deleted].=A0De mortuis [rest of suspected
> > >>>>>> insult deleted], as my momma used to say.

None of the nasty things that Lew has said or implied about me are at
all true.

> > >>>>> My mom used to say "facit" too, though not in front of company.
> > >>>> And the horse it rode in on?
> > >>> Mike, you obviously studied Classical Latin, not just (or instead
> > >>> of?) Church Latin. =A0My high-school Latin teacher would've been
> > >>> proud of you.
> > >> I did, though I'm not sure how a collection of bad puns displays
> > >> that. One of my (public) high school's English teachers was a
> > >> classicist, and she had permission to teach latin as long as she
> > >> could fill the classes. =A0I expect Latin ended there when she
> > >> retired. My son's now taking Latin, though that's more natural,
> > >> since his high school is run by Jesuits.
> > > Traditionally, there are four ways to pronounce Latin: classical,
> > > ecclesiastical, Jesuit and wrong.
> > And the last is probably the most common ...
> Indeed, the student's still lament:

The lamentable thing here is the sheer volume of non-Java-related
traffic that is being posted to this newsgroup lately.

bbound@gmail.com wrote:
> On Nov 10, 4:50 pm, John W Kennedy <jwke...@attglobal.net> wrote:
>> Mike Schilling wrote:
>>> Lew wrote:
>>>> Damn it. [implied insult deleted]
>>>> [implied insult deleted]. De mortuis [rest of suspected
>>>> insult deleted], as my momma used to say.
> 
> None of the nasty things that Lew has said or implied about me are at
> all true.

Out of curiosity, what does this have to do with Java? :-)

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth