Adam Heath wrote:
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.
Huh? If you're referring to dates prior to the epoch, then yes - there is a design flaw there. I never thought of that before, and it definitely needs to be fixed.
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?
It's just an encoding method. I could have done bit shifting instead. Three years will be encoded as three years - leap years/seconds don't have anything to do with it.
Now, if we really do want to stick with this TimeDuration class, the code will get *very* complex.
Why? Aside from the bug mentioned above, the class works. Why are you so determined to change it or eliminate it?
