Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
It would be nice if we could do math with those values. If creating a
widget takes 1 minute and 30 seconds, how long would it take to create
one hundred widgets? If a production run of 100 widgets starts at 9:00
AM Thursday, at what time will the production run end? These are the
kind of problems I hoped to solve with this class and others.
Maybe pattern it after BigDecimal. The benefit there is that things
like groovy will magically work with it.
The main issue, is that when a lower field becomes larger, you may not
be able to rollover to a larger field. Ie, some days have 61 seconds,
some years have an extra day. So once you do math, you may have to
carry the mutations around as extra data. Unless someone else has
some insights.
You're still mixing a duration of time with a calendar. A duration of
time must be expressed outside of a specific calendar
It is acceptable to have any value in any of the fields, so don't get
too hung up on what the fields contain. In the widget example, it would
be perfectly acceptable to have a duration of 100 minutes and 3000 seconds.
Another way of looking at it: TimeDuration is elapsed time. That is not
the same as wall clock time. You're mixing elapsed time with wall clock
time.
If a sprinter runs the 40 yard dash in 5 seconds, that 5 seconds will
always be 5 seconds - regardless of whether or not he ran it in a leap year.
