Adam Heath wrote:
Adrian Crum wrote:
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.
This is the most major actual real bug I've found. As such, I have
used git to rebase back to before I rewrote it(which I may end up
throwing away anyways), and am writing just test cases against your
current code.
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?
I'm not trying to get rid of it. I'm trying to understand under which
circumstances it is used.
Remember, I am not you, and haven't seen the same things you have. I
don't know what caused you to write this, what situation you were in
when you decided to use a full class for duration management. If I am
having questions, it's obvious that I don't understand, so don't just
wave it away.
Fair enough. I'm not feeling well today, so I'm being a little testy. My
apologies.
TimeDuration is one class in a number of classes used for calendaring. A
Work Effort GenericValue, a Temporal Expression, and a TimeDuration
combined together can express any event.
I've asked quite a few questions about the implementation. Some have
been bugs, others are changes you hadn't gotten around to doing yet,
and others are just different ways of doing things. This shows that I
am understanding some parts, but not others. What we will get out of
that will be better than what we had before.
I agree. I appreciate the interest you've taken in it.
The reason I am asking so much, is there may be a better way to do
things. If there isn't, that's fine. If you've done already done
reasearch, and finally settled on this system, that's fine too, but
then you need to tell me why that is. I've shown enough little burrs
with this code that it makes me want to use some already implemented
system that has all the bugs worked out, rather then reinventing the
wheel, and fixing the same set of bugs that someone else has already
solved.
Agreed.
The main thing to keep in mind is that a duration of time must be
expressed outside of a specific calendar. Take your three years example
- how many days would that represent? There is no way to know unless the
duration is applied to a calendar. Even then the number of days could be
anything - depending on the year and the calendaring system.
If you take the long encoding/decoding out of the class you will see the
essence of what it does. It's a simple container for a set of values.
Those values can be applied to a Calendar instance to derive a date.
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.
