>>> simpler. It could use some TLC. >> Ok, sorry to say this, but TimeDuration needs to be >> removed. >> com.ibm.icu.text.DurationFormat, which handles things like >> 2 days from >> now and 3 hours ago, uses a long for the duration. >> >> Additionally, trying to duplicate leap year calculation, >> there is not >> a whole number of days in a year(it's not quite >> 365.24). If long is >> good enough for icu, then why should we try to use >> something else? > > Grasshopper, > > TimeDuration is not concerned with such details. They are delegated to the > Calendar class. > > Tell me, using com.ibm.icu.text.DurationFormat - how do you add two durations?
I'm still waffling. Still more issues. new TimeDuration(cal, cal) doesn't handle when one cal is 0, and the other is negative; in detail, if I try to handle a duration with a border of 0, and a border of -1 month, it comes out quite wrong. fromLong(long) does its own internal math, not using any Calendar class. What happens with you specify a duration of 3 years, then convert that to a long? How does leap year/leap second fit into that? You add 2 durations by adding their long values, of course. DurationFormat considers a duration has a plain, simple long. Here's another way of looking at it. Object.wait(and friends) have a timeout parameter, that is a long, which represents milliseconds. Java1.5 added more variants, that still take a long, but then also take a TimeUnit enum. In either case, the long represents a duration of time, and, it's not an object. Even in the thread pool stuff in java.util.concurrent, they use a long+TimeUnit pair to represent periods/durations. Now, if we really do want to stick with this TimeDuration class, the code will get *very* complex. If you originally want a duration of 50 billion milliseconds, then that's exactly what you will get. However, if you request a duration field that just so happens to have leap-year/leap-second mutations, then calling toLong on it doesn't fully make sense. You can only get the correct value when you add it to a concrete date. This implies that you can't encode a duration into a long. ps: your earlier comment about using an array of shorts to save memory doesn't apply; bytes, shorts, characters are all stored as ints internally.
