Name: rl43681 Date: 10/02/2002


FULL PRODUCT VERSION :
all Java versions since at least 1997

FULL OPERATING SYSTEM VERSION : all

ADDITIONAL OPERATING SYSTEMS : any Java version since ages



A DESCRIPTION OF THE PROBLEM :
The fact that the GregorianCalendar month is 0-based (and
not the day, or year, minute, second) must be *much* better
documented that it is now. At this point this is basically
a programmer's time trap, and no-one needs that.
This below is what I wrote as a comment to one of the
numerous existing bug reports on this, before realizing
these were all already arrogantly closed by a "It's not a
bug, it's a feature" answer.

(quote)
If you want java to succedd, you *definitely* have to make
sure that this kind of "little" usability thing is BETTER
DOCUMENTED. This calendar "feature" of yours should appear
at the beginning of the GregorianCalendar class
documentation as a wartning, not as an afterthough lost in
the superclass's specific function description (even there
it can be missed). A few hours lost times legions of
programmers with this kind of oversight translates into a distinct buzz
that java is more frustrating and less productive than the
other "more dumbed down option".
(end quote)

Have a nice documentation fixing day.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
read your closed bug reports on GregorianCalendar, and weep

EXPECTED VERSUS ACTUAL BEHAVIOR :
I expected higher productivity with Java than with Visual
Basic. I doubt it now.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
Implement some kind of feedback loop between "it's not a
bug, it's a feature" responses in your bug database and the
JDK documentation.

Stands to reason, doesn't it?
(Review ID: 163505)
======================================================================