Just in case you weren't aware, JSR-275 was rejected last month: http://jcp.org/en/jsr/detail?id=275 Not that that means anything, just an FYI.
Regards Scott HotWax Media http://www.hotwaxmedia.com On 22/04/2010, at 3:15 AM, Adrian Crum wrote: > Joda Time claims to fix the problems with the Java date/time API, while it > duplicates the problems in the Java date/time API. The only real advantage to > Joda Time is the additional calendars - which OFBiz already has in the ICU4J > library. > > The author of JSR-310 complains about Joda in the spec and claims that > JSR-310 is better than the Joda Time API. I don't believe JSR-310 will become > a part of the Java spec any time soon. JSR-275 is more mature and has seen a > lot more activity than JSR-310, yet even that doesn't have enough votes to > get it into the Java spec. > > If we actually had a choice, I would vote for using JSR-310 over Joda Time. > The problem is, there is no library that I can find. So far it appears to be > a draft specification only. > > In the meantime we could really use a simple set of date/time classes that > take the guesswork out of handling dates/times. I started with the Quantity > pattern and included some good ideas from JSR-275 and JSR-310. I believe the > result is easy to use and reliable. > > Mini-language has a set-calendar element - maybe that is the end result of > the conversation you were thinking of. > > -Adrian > > Bob Morley wrote: >> Adrian Crum-2 wrote: >>> In the meantime, I'm working on a date/time library that includes an >>> ElapsedTime class (an improved TimeDuration class) that follows Martin >>> Fowler's Quantity pattern. >>> >> I am certainly not interested in re-inventing the wheel here. I know in our >> solution we are going to allow entry against a ProductionRun task in hours >> and I will want to leverage this TimeDuration as you have in >> WorkEffortServices. >> Way back in 2006 - 2007 there was talk of including Joda time into Ofbiz (at >> the time the thread dealt with wrapping up time related functionality in >> minilang). Do you know why we decided to back-off Joda time (if there was a >> conscious decision there)? My understanding is that JSR 310 (new java >> date/time apis) that has been proposed for Java 7 is largely based on Joda >> time. Being that the lic. is favorable, I would have thought pulling in and >> using their Duration might make sense vs. maintaining our own TimeDuration >> and/or a new date/time library? Very interested in your thoughts because >> this really appears to be something in your wheel house.
smime.p7s
Description: S/MIME cryptographic signature
