Yes, you are right or course, if there is only going to be one way to handle dates and times in Java it will need to be that complicated. On the other hand, when you check out a DVD at Blockbuster that is due in three days you are not that interested in what time it will be in Uzbekistan when it is due. You cannot return it an hour after closing time because of daylight savings time. Blockbuster assumes that their employees, their customers and their computers will all be asleep between 1:00 and 2:00 am and will adjust their clocks when they boot up the next day. Blockbuster does not worry about the slowing of the rotation of the Earth.
My point is not that the Java time/date classes are wrong, I just think that those other implementations -- the ones that gloss over the complicated stuff -- are easier to use for many day-to-day tasks.
BigLee
At 12:07 PM 6/16/2003 -0500, you wrote:
Quoting BigLee Haslup <[EMAIL PROTECTED]>:
> The Java Date/Time classes are exactly what you need to launch a > probe > to Uranus but are maddening to try to use for business calculations. > One > always feels like Captain Kirk trying to get Mr. Spock to answer a > simple > question.
I only half agree. Yes, the 0-based numbers are strange, and I appreciate that things
could be simpler if they were 1-based.
java.util.Date is useful for absolute times - milliseconds (sans leap seconds) since 1970-
JAN-01 midnight GMT. java.util.GregorianCalendar makes a fine tool for interpreting
those dates according to the calendar most of us use, and java.util.TimeZone helps to
give a locale to the information.
The trouble with using Java for business calculations isn't with Java per se, it's that it
exposes the issues glossed over by other implementations. For example, I've never
seen a time zone in Access, Excel, or Oracle, but if you're dealing with worldwide
shipments and your business rule tells you to flag shiments that should have been
delivered yesterday, you have to have a precise definition of what "yesterday" means. If
you know the date of an occurrence but not its time, what time do you assign it for storage
in a java.util.Date? (I suggest noon, but you also need to extend java.util.Date and give it
variable precision.)
In my experience, people haven't spent much time understanding time zones. People
know they're in the Eastern time zone, and they know how to convert the time to call
family in some other zone, but other than that, people like to guess about such things
because they appear so simple. (Any one time zone is simple enough, but even time
zones change over time.)
Tread carefully when dealing with time, in Java or in another language, particularly if
you're dealing with an international application.
Best regards, Jim
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
