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
