-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.1.6, 1.3.0
-
generic
-
generic
GregorianCalendar has some undefined behaviour on daylight saving time boundary.
1) daylight saving start time. 4/4/99 2:00am in US/Pacific time zone.
By definition, 1:59:59am PST is immidiately followed by 3:00:00am PDT. There is no time representation between these two time.
GregorianCalendar(1999,3,4,2,30,0) gives you 1:30:00am PST. However, if we take this constuctor as 2 hour 30 min after midnight (beginning of day). This should give you, 3:30am PDT. This is consitant behaviour as other field, like 9/31 gives you 10/1.
2) daylight saving end time. 10/31/99 2:00am in US/Pacific time zone.
Again, by definition, 1:59:59am PDT is immidiately followed by 1:00:00am PST. The problem here is no GregorianCalendar constuctor getting daylight saving time assumption.
GregorianCalendar(1999,9,31,1,30,0) can be either 1:30am PST or 1:30am PDT. This implies it need another constuctor to specify daylight saving assumption. C library mktime() uses tm_isdst as positive (daylight), 0 (standard), minus (let library determine).
koushi.takahashi@japan 1999-10-26
1) daylight saving start time. 4/4/99 2:00am in US/Pacific time zone.
By definition, 1:59:59am PST is immidiately followed by 3:00:00am PDT. There is no time representation between these two time.
GregorianCalendar(1999,3,4,2,30,0) gives you 1:30:00am PST. However, if we take this constuctor as 2 hour 30 min after midnight (beginning of day). This should give you, 3:30am PDT. This is consitant behaviour as other field, like 9/31 gives you 10/1.
2) daylight saving end time. 10/31/99 2:00am in US/Pacific time zone.
Again, by definition, 1:59:59am PDT is immidiately followed by 1:00:00am PST. The problem here is no GregorianCalendar constuctor getting daylight saving time assumption.
GregorianCalendar(1999,9,31,1,30,0) can be either 1:30am PST or 1:30am PDT. This implies it need another constuctor to specify daylight saving assumption. C library mktime() uses tm_isdst as positive (daylight), 0 (standard), minus (let library determine).
koushi.takahashi@japan 1999-10-26
- duplicates
-
JDK-4247196 java.sql.Timestamp broken in some time zones
-
- Closed
-
-
JDK-4312621 (cal) API: DST transition handling is ambiguous in GregorianCalendar
-
- Open
-
- relates to
-
JDK-4234799 DateFormat maps two DIFFERENT times into the same numeric
-
- Closed
-
-
JDK-4248500 roll methods for GregorianCalendar not working properly for October 31
-
- Closed
-