commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [lang] initial crack at DateRange class
Date Wed, 01 Mar 2006 21:08:54 GMT
On Wed, 2006-03-01 at 09:26 -0800, matthew.hawthorne wrote:
> Stephen Colebourne wrote:
> > The question with DateRange is whether this is a direction that [lang] 
> > should go in. Joda-Time has demonstrated that there are many weird and 
> > strange things to consider when dealing with dates.
> Understood.  Well, in the meanwhile, it's in Bugzilla until a final 
> yes/no decision is appropriate.  I had a need for the class, but if 
> [lang] isn't a good fit, then that's obviously fine too.

i've been using similar DateRange objects for the last three years. they
proved very useful and popular. there are lots of very useful set
theoretic operations possible on collectives. 

however, long term issues with this kind of formulation have been
discovered. dates have a lot of wrinkles and the java 2 datetime
framework has major issues (including differences between JVMs). fixing
these requires lots of code gymnastics.

now that we've finally at the optimisation stage, we're seeing a 5-10%
performance degradation due to the initial design mistake of using
DateRange's. we needed business day ranges not date-time intervals. this
leads to difficulties handling time zones correctly and to the need to
normalise before comparisons. these can be fixed but not in a performent
fashion. so it looks like sometime soon i'm finally going to have my way
and rip them all out :) 

the replacement will use performent immutable day objects which wrap int
primitives (number of days since epoch) for all basic calculations and
JODA time for the complex, calendar related stuff. i had been very
worried about replacing the 50 or so utility methods but thankfully they
were unit tested and found the combination of JODA time and day business
objects quick and powerful. maybe i'll have other things to say in three
years time but ATM IMHO lightweight day objects and JODA time seems like
a much better approach.

so, i worry that we may be misleading users about best practise by
advocating using the java date framework. 

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message