Possible bug in Calendar

[Mike Schilling]

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.

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Martien Verbruggen]

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

 

[Lew]

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.

 

[Joshua Cranmer]

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

 

[Eric Sosman]

I tend to agree about Date. Calendar is a bit klunky, perhaps innately
due to the irrational psychosocial nature of human calendars, and its
'clear()' method is truly confusing. So I agree that it has flaws, but
the blanket condemnation of Calendar as "flawed" implies that it is far
less useful than it really is.

Here are two things I've observed:

1) Every date/time package I've ever run across in any
programming language has been deficient in one way or another,
sometimes to the point of looking utterly stupid, and

2) Many of those date/time packages were designed and
implemented by people a whole lot smarter than I am.

From these observations, I draw two conclusions:

A) The ways people reckon dates and times are far more
complicated than a naive glance suggests, and

B) It's folly to throw words like "stupid" around. (Or
stupid to throw words like "folly" around; I can never keep
that straight.)

As examples of (A), consider "same time next month" when
uttered on January 30, or "same time next year" when uttered
on February 29. Even "same time tomorrow" will be tricky in
my locale for most of this Saturday.

 

[Arne Vajhøj]

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

 

[Owen Jacobson]

     Here are two things I've observed:

     1) Every date/time package I've ever run across in any
programming language has been deficient in one way or another,
sometimes to the point of looking utterly stupid, and

Have you looked at PostgreSQL's implementation of INTERVAL, TIMESTAMP,
and DATETIME types? It's about on par with Joda for "least-ass time
API": it gets timezones right, has a fairly complete arithmetic model
based on points in time and un-anchored intervals ("1 month" is an
interval), and it's high resolution (seconds to six decimal places).
It also uses a fairly natural convention for arithmetic: intervals
whose units are seconds are exact, and intervals whose units are
conventional clock or calendar periods like hours or months are
context-dependent. Thus, 'now + 1 month' is the last day of November
(since today is the last day of October), but 'now + 31 days' is
December 1st, and 'now + 2646025 seconds' is also December 1st.

 

[Lew]

Have you looked at PostgreSQL's implementation of INTERVAL, TIMESTAMP,
and DATETIME types? It's about on par with Joda for "least-ass time

There isn't any such Postgres type as "DATETIME".
<http://www.postgresql.org/docs/8.3/interactive/datatype-
datetime.html>
There's DATE and there's TIME.

API": it gets timezones right, has a fairly complete arithmetic model
based on points in time and un-anchored intervals ("1 month" is an
interval), and it's high resolution (seconds to six decimal places).
It also uses a fairly natural convention for arithmetic: intervals
whose units are seconds are exact, and intervals whose units are
conventional clock or calendar periods like hours or months are
context-dependent. Thus, 'now + 1 month' is the last day of November
(since today is the last day of October), but 'now + 31 days' is
December 1st, and 'now + 2646025 seconds' is also December 1st.

Postgres follows the SQL standard wrt to datetime types. Probably the
least compliant RDBMS in this area is Access, followed by MySQL.
MySQL particularly has an idiosyncratic semantic for TIMESTAMP.

 

[Eric Sosman]

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.

 

[Harold Yarmouth]

I can't. It's just the code that's out there. You get a feel for these
things working with, seeing, using, and writing large amounts of code.
So you will have your answer if and when you are sufficiently
experienced. If you don't have it yet, just keep working with Java and
the patterns will become apparent to you in the fullness of time.

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.

 

[Harold Yarmouth]

And since when is Java only for business applications?

Since never, but it is predominantly used for business applications at
this time.

Nice to know that you're so culturally sensitive in ignoring

"Cultural sensitivity" is neither here nor there. "Cultural sensitivity"
is not a major concern of programming language or API design. It may be
a concern of application user-interface design, but that's a whole
different kettle of fish.

Imagine if it were otherwise -- Calendar would not accept dates before
4004 BC, to avoid offending Christians, or after 2012, to avoid
offending Mayans. There'd be something to prevent the coding of genetic
algorithms. SecureRandom and all of the crypto would be missing, since
some cultures strongly frown upon any kind of concealment or disguise of
information, either from people in general or specifically from
government or religious authority. Programs written in Java would refuse
to work on Sundays. The sound, MIDI, and MP3 libraries would refuse to
work when the current locale setting was Afghanistan and the system
clock set prior to around mid-2003. And so forth.

That is the sort of mess we'd have if we took
designing-in-cultural-sensitivity to its logical conclusion.

The API and language should provide the application designer with the
tools to a) write the internal business logic to use standard,
internationalized units and b) localize the user interface.

Which means using the plain-Jane Gregorian calendar under the hood in
Date and other business objects related to dates, with DateFormat or
other similar classes providing translations into locale-specific
representations.

 

[Harold Yarmouth]

Well, I tried to give you the benefit of the doubt about being an
asshole, but you had to raise the ante by being an ignorant racist, too.

Do not lie about me in public again. I am not either an asshole or an
ignorant racist.

You, on the other hand, appear to be at least the former of those two.

It is certainly not racist to make an observation about what is standard
practice in commerce, as you seemed to be implying. It is merely making
an observation.

People are free to use their older calendars to schedule religious
ceremonies or whatever. However, such things have no place in core
utility classes in a programming language API; they belong in
localization code affecting input parsing and output display, i.e. in UI
code, rather than the code for business-layer objects, where they belong
in the standard API at all rather than in third-party libraries.

That is not a racist remark either. It is merely an observation of fact.
Localization belongs in the UI layer, not in the business layer. The
alternative is catastrophic: applications that communicate with each
other won't be speaking the same language.

It's no more racist to say "localization belongs in the UI layer" than
it is "insensitive to someone's time zone" to say that the internal,
file, and network representations of times should be in GMT with time
zones dealt with in the UI layer.

It is merely logical.

 

[Harold Yarmouth]

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.

 

[Harold Yarmouth]

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.

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.

The Calendar class is obviously polymorphic

I didn't say anything about whether or not something IS, I said
something about whether or not there is a strong reason for it to BE.
The two are not identical.

 

[Arne Vajhøj]

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

 

[Harold Yarmouth]

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.

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

No, it is the single most common usage of Calendar.


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