DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=25560>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=25560 DateUtils.truncate() is off by one hour when using a date in DST switch 'zone' ------- Additional Comments From [EMAIL PROTECTED] 2004-07-04 21:34 ------- After some more testing, the light bulb came on as to why the Calendar.add method seemed to be overshooting the correct date and subtracting 6 hours instead of five. This is probably a "duh" for most everyone else, but it took me a few minutes to see it. The DateUtils.modify method, which does the gruntwork of the round and truncate methods, was subtracting the number of hours from the date being rounded/truncated. In this paricular case, it was subtracting 5 hours to get from 05:00 to 00:00. However, since the scenario happened to cause this across a DST enablement, Calendar.add was treating the time between 02:00 and 03:00 as non-existing, so subtracting 5 hours from 05:00 was giving 23:00 on the previous day, which is technically correct. But for a rounding/truncation method, this is not appropriate, so my earlier solution of calculating the desired hour value and using set does appear to be appropriate. Note that I did a few tests on rounding across the 02:00/03:00 barrier, and the rounding also "ignores" the missing hour. So for example, rounding 01:40 gives 03:00, and rounding 02:40 give 04:00, which IMHO are both correct, since the 02:00-03:00 hour does not exist. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
