The bug fix uses the new methods in UtilDateTime.java. The existing code performs date calculations
by doing arithmetic on millisecond values. That simply doesn't work. If it did, there would be no
need for classes like java.util.Calendar and java.util.TimeZone.
I get the feeling the objections are being raised over the new UtilDateTime.java methods. I've been
using the new methods here for about a month. I have a calendar component that uses them and it
works flawlessly across time zones, locales, and DST changes.
Chris Howe wrote:
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
In other words, it's okay for the system to function incorrectly, as
long as it consistently
functions incorrectly.
;)
If you prefer to keep the Workeffort calendar broken, that's fine
with me. When new users ask why
release version 4 has only 29 days in November, I can point them to
this discussion and let them
know that November 30th was a new feature that didn't make it into
the release.
Can't wait to see that on a change log somewhere :-). Since there is
calendar usage in 4.0 (Rental and Manufacturing to my knowledge) I see
the issue as a bug fix. I think the question really is, how much of
the solution is new feature and how much of it bug fix. Can you get
the correct number of days in November without the entire solution?
