Possible bug in Calendar

[Arne Vajhøj]

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.

Sure it is.


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.

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

 

[Arne Vajhøj]

Yes, it is.

Glad you agree with me.

I am an experienced programmer

Sorry - nobody will believe that.

You don't read documentation.

You don't understand object oriented principles.

No, it wouldn't.


Who said anything about that?

You did. See above.

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.

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

 

[Arne Vajhøj]

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

Lew wrote elsewhere in this same thread:

I'll take that as a "yes".

Another good example of where you completely misses the point.

Arne

 

[Arne Vajhøj]

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

 

[Joshua Cranmer]

Lew wrote elsewhere in this same thread:

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.

 

[Joshua Cranmer]

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.

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.

 

[Lew]

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.

 

[Tom Anderson]

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

 

[Arne Vajhøj]

None of which I am aware.

Ah well.

He could have been your cousin or something.

Arne

 

[Arne Vajhøj]

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

 

[Harold Yarmouth]

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.

 

[Harold Yarmouth]

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.

 

[Harold Yarmouth]

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

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.

 

[Harold Yarmouth]

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.

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

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

 

[Harold Yarmouth]

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.

 

[Harold Yarmouth]

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.

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.

 

[Harold Yarmouth]

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.

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.

 

[Harold Yarmouth]

There are.

No, there aren't.

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

 

[Harold Yarmouth]

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.

 

[Harold Yarmouth]

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.