From: SourceForge.net <no...@so...> - 2008-02-15 12:16:37
|
Bugs item #1894405, was opened at 2008-02-15 13:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115494&aid=1894405&group_id=15494 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: f bertilsson (fbertilsson) Assigned to: Nobody/Anonymous (nobody) Summary: Hour(Date, TimeZone) skips extra hour on DST end Initial Comment: The Hour class does not work correctly when the daylight savings time ends; one hour is duplicated. Using the java.util.Calendar class and the Hour(Date, TimeZone) constructor followed by a call to getFirstMillisecond(Calendar), the following error occurs (the two millisecond value on each row should be equal): 28.10.07 00:00 Hour: 00 Calendar ms: 119352240 Hour (ms): 119352240 DST:true 28.10.07 01:00 Hour: 01 Calendar ms: 119352600 Hour (ms): 119352600 DST:true 28.10.07 02:00 Hour: 02 Calendar ms: 119352960 Hour (ms): 119353320 DST:false The reason is that constructing a point in time using <year, month, day, hour, minute, second, ms> is ambiguous, see the implementation of Hour.getFirstMillisecond(Calendar calendar). When daylight savings ends, there will be two hours with the same combination of values, but they do differ in values of Calendar.getTimeInMillis(). The Calendar class has no way of knowing which of the two points in time the caller intends, and picks one of them. A good way to solve this problem is to always store the millisecond value ("the current time as UTC milliseconds from the epoch" as stated in the Java API doc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115494&aid=1894405&group_id=15494 |