If you look through the dev mailing list for February you will see where Adam and I discussed the class's design. That should give you some insight into why things look the way they do.
Most of the work that went into TimeDuration was the result of this Jira issue: https://issues.apache.org/jira/browse/OFBIZ-3125 Originally, the class supported a negative duration (Today @ 11:00PM to Today @ 10:25PM equals negative 35 mins) but Adam thought there was a need to support a negative value for a single field. When I first researched the issue, I had suggested splitting duration values in the database (separate fields for hours, mins secs, etc) but it was recommended that we keep durations stored in the database as a long so that duration values can be compared in SQL queries. TimeDuration encodes/decodes long values that can be compared in SQL queries. To summarize, TimeDuration is a class designed by committee. If you have a better design, I would be interested in seeing it. 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. -Adrian --- On Tue, 4/20/10, Robert Morley <[email protected]> wrote: > From: Robert Morley <[email protected]> > Subject: Re: Regarding SVN commit r892904 > To: "[email protected]" <[email protected]> > Date: Tuesday, April 20, 2010, 10:48 PM > Lol of course not, I was just > suggesting that strictly speaking that constructor misuses > the makeNegative. With classes like this it is > probably better to have a single instance variable store the > ms for the duration. Just impressions when previewing; > if there us no value let's ignore. > > I may reply quarter to ten (10,-15). > > I will take a look at the lookup screen as per your > direction. But I can't imagine it makes use of > TimeDuration directly, it would have to convert 4.5 to long > or to (4,30). > > Bob > > On 2010-04-21, at 1:26 AM, Adrian Crum <[email protected]> > wrote: > > > If you spend a little time with Work Effort's > Estimated Milliseconds field, you will find that there is a > lookup screen that will allow you to enter 4.5 hours. > > > > TimeDuration will encode/decode long values. You don't > need to use the int constructors. > > > > If you were entering 10 months into a field, I'm sure > you would enter it as 10 months, not one year plus negative > 2 months. When someone asks me for the time, I usually don't > reply "11:00 PM minus 35 minutes." > > > > -Adrian > > > > > > --- On Tue, 4/20/10, Bob Morley <[email protected]> > wrote: > > > >> From: Bob Morley <[email protected]> > >> Subject: Re: Regarding SVN commit r892904 > >> To: [email protected] > >> Date: Tuesday, April 20, 2010, 9:49 PM > >> > >> > >> Adrian Crum wrote: > >>> > >>> We have the TimeDuration data type for the > >> estimated/actual time. > >>> > >> > >> Are you referring to > >> org.ofbiz.base.util.TimeDuration? The intent > would > >> seem to be that we would define fields in the > entity model > >> as (what results > >> to a Long) and use this class for simple (manual) > >> serialization / > >> deserialization. That would work well for > WorkEffort > >> fields as you have > >> indicated. > >> > >> However, in taking a quick glance at TimeDuration > a couple > >> of things struck > >> me ... > >> > >> 1) I am forced to use a constructor that requires > int for > >> the components of > >> the duration. If I was to build a screen > that allowed > >> the user to indicate > >> 4.5 hours (for example) I could not use this class > to > >> easily convert to my > >> long value for persistence (if that is part of > its > >> intent). > >> > >> 2) The makeNegative usage looks incorrect in the > >> "component" constructor -- > >> say I am going to new TimeDuration(1,-2,0,0,0,0,0) > I think > >> my expectation is > >> my duration would be 10 months (1 year - 2 > months); but > >> what would happen is > >> since one of the components is negative it would > negate all > >> components and I > >> believe I would have a duration of -14 > months. (In > >> fairness, the only > >> existing use case that would appear to use > negative > >> duration is in > >> WorkEffortServices and it is using the constructor > that > >> takes a long). > >> > >> Bottom-line; I agree I think we should leave these > on > >> WorkEffort as stored > >> in milliseconds and leverage TimeDuration. > If either > >> of these two points > >> make sense; perhaps we should cut a minor JIRA to > resolve > >> them if you feel > >> they warrant potential repair. > >> --View this message in context: > >> http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2018379.html > >> Sent from the OFBiz - Dev mailing list archive at > >> Nabble.com. > >> > > > > > > >
