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. >
