Possible bug in Calendar - Java
This is a discussion on Possible bug in Calendar - Java ; 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 ...
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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!
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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.
-
Re: Possible bug in Calendar
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
-
Re: Possible bug in Calendar
On Nov 5, 1:52 pm, 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