Skip to main content

Dates

3 replies [Last post]
scolebourne
Offline
Joined: 2003-06-20
Points: 0

I have hesitated to mention dates as a separate topic because I have a vested interest. However, numerous threads have mentioned dates as a pain that people would like to sort out.

The JDK dates have numerous issues, including the Date class, with lots of deprecated methods and should have been immutable, plus the Calendar class, with its poor internal design that can be highly unreliable.

My interest? I look after Joda Time, a rewrite of dates and times (http://joda-time.sourceforge.net). The trouble is that there is a case to argue that libraries can be better written and more responsive when outside the JDK.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lucretius2
Offline
Joined: 2004-12-19
Points: 0

Joda Time is clearly a great achievement. But it seems to have replaced something that's broken and complicated (Java dates) with something that's correct and very, very complicated.

As an illustration, here are the classes in just one of the subpackages, org.joda.time.field:

[b]AbstractPartialFieldProperty
AbstractReadableInstantFieldProperty
BaseDateTimeField
BaseDurationField
DecoratedDateTimeField
DecoratedDurationField
DelegatedDateTimeField
DelegatedDurationField
DividedDateTimeField
FieldUtils
ImpreciseDateTimeField
LenientDateTimeField
MillisDurationField
NonZeroDateTimeField
OffsetDateTimeField
PreciseDateTimeField
PreciseDurationDateTimeField
PreciseDurationField
RemainderDateTimeField
ScaledDurationField
StrictDateTimeField
UnsupportedDateTimeField
UnsupportedDurationField
[/b]
Over-engineered perhaps?

Now I don't have a particularly positive contribution to make, such as my own simpler date/time library (!), but I'd be willing to bat a few ideas around for how the Joda API could be simplified. I suspect this would involve undoing some of Joda's design decisions, such as the focus on type-safety which (I suspect) has resulted in so very many classes.

mthornton
Offline
Joined: 2003-06-10
Points: 0

In my view your (joda) most basic 'instant' is far too complicated. I would have made the simplest class just hold time in UTC relative to some base date and basic string conversions to/from ISO8601 form. No Chronology or other issues.

Incidentally in much of my own work I use floating point values for time. This is because durations are calculated using floating point and conversion to integer is an expensive operation. I don't know whether floating point based time is sufficiently common to warrant support in standard packages.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Messing with Date and Calendar can really be a pain in the behind. I have had a short look at Joda and it makes much more sense. I particularly like having Date, Time and DateTime. This alone would probably prevent the common error that dates suddenly shift a day back because the server is in a time zone West to yours (because dates are saved with 00:00:00 as time, so they become the day before 23:00:00 one time zone West). And I very much like a time period class. And Januar == 1 ... December == 12! A ISO8601 calendar.

So, throw out java.util.Date/Calendar etc. (not literally of course, for compatibility) and add a package java.date.* or java.lang.date.* or .datetime.* or something to the like.

I see just one problem: java.sql.Date and java.sql.Time inherit from java.util.Date, and they would still have to do so for compatibility. But it would be nice and sensible to use the new Joda-like dates and times instead, so have the sql Date and Time inherit from them. I guess there is no solution for this.

Monika.