Discussions

Blogs: Cameron Purdy: Useless data types: Date, Date, Time, Timestamp

Bookmark and Share Get thread feed

  1. Cameron Purdy: Useless data types: Date, Date, Time, Timestamp (3 messages)

    Cameron Purdy, in "The Seven Habits of Highly Dysfunctional Design," promises us seven dysfunctional designs in Java, and starts with "Useless data types: Date, Date, Time and Timestamp."

    He gives the history of java.util.Date (and its successor, java.util.Calendar) and shows what wasn't quite right about them, and finishes with this gem:
    As far as java.util.Calendar goes, I'm sure it has a purpose, but since we've been on the Gregorian now for several friggin' centuries (and with no sign of imminent change), I think we'd be safe having Calendar be one of those classes that is neither seen nor heard except in the 0.000001% chance that you actually need to do something with the scrolls of dead monks.
    Apparently those of us who do use alternate Calendars are to be left out a bit, although in all fairness, using a lunar calendar isn't supported by the JDK without external libraries in any case. :)
    Reply to this

    Threaded Messages (3)

  2. Alternative is available[ Go to top ]

    I am not sure Date is useless. I frequently need to store a date :)

    Anyway, there is a very high quality replacement called Joda-Time. I can recommend it to anyone doing even the simplest of date/time manipulations.

    http://joda-time.sourceforge.net
    Reply to this Reply to original

  3. Gem?![ Go to top ]

    I hope you're writing in jest there.

    Many calendars exist in the world, incl. Jewish, Islamic, various fiscal and financial calendars, calendars you may want to create for simplifiying mathematical and other solutions, such as Julian, etc.

    But, of course, there are other purposes that Calendar serves:

    Calendar instances if made by getInstance are locale-aware. For example, the method firstDayOfWeek will give you either Sunday or Monday, depending on the local tradition.
    Reply to this Reply to original

  4. Rather silly rant[ Go to top ]

    Its hard to tell with satire what part of it is meant to be stupid-funny and what part is supposed to be serious. This rant shows the great loss from lack of editorial review that blogs suffer from.

    As to Date Class -

    1. The Value Object question is irrelevant. All the mutator methods are deprecated except setTime() so that might be a hint about how to use this class safely. Any reasonable design persists the millisecond value NOT the Date object value. Date objects are primarily ueseful as return values and method parameters for DateFormat and JDBC methods, etc.

    2. The java.sql.Date class is an elegant and useful adaptor between Java dataes and SQL dates in my experience.

    3. The operating system call level interfaces on many systems have all millisecond granularity for 20 years or so, altough most devices don't actually yet support even that resolution. This seems to be very slowly moving target.

    4. The Timezone issue is also irrelevant. Take a look at the SimpleTimeZone class. The designers of these classes have anticipated changes and handled the tradeoffs between performance and flxibility rather well. In the US every State, or even parts of states, can change their own daylight savings times at will, and some do. This is an ongoing issue that Java handles very well, not something like Y2K that is looming in the future.

    5. Calendar class solves real problems with I18N in a way that is so elegant that few programmers ever even notice it.

    And so on...

    Many of the same kinds of rejoinders can be made to the rants on BigDecimal and "useless" interfaces, and the Exception model. All of these tools do the job they are designed to do very nicely. These blog rants are like anti-patterns about how the tools fail when they are mis-applied.
    Reply to this Reply to original