I pretty much agree with you and I've had enough of this. I'm not sure
how this got so far off track from where I thought it was going. As
much as I feel date-time handling is lacking in the java.util packages
I had no intention to redesign anything or even to criticize it.
If anything I wanted to point out a misuse of the constants even though
such use is hinted at (and I guess encouraged) in the documentation.
What I think is the real problem with the Calendar class is mostly its
documentation. It requires a lot to be assumed and inferred. I also
wanted to point out that what many perceive as the "Java date"
specification is the specification of depreciated methods in the class
java.util.Date. The documentation explicitly states that " As of
JDK 1.1, the Calendar class should be used to convert between dates
and time fields and the DateFormat class should be used to format and
parse date strings. The corresponding methods in Date are deprecated."
This puts the onus of documenting how such conversions are to be
performed and what values the months have on the Calendar class.
Unfortunately, I don't think it does a very good job at it. Of course
it makes sense that the same values for the months are used, it just
isn't documented that they are.
I'd like to apologize for prolonging the life of a silly thread. That
said, I'm done.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
