-
Enhancement
-
Resolution: Duplicate
-
P4
-
None
-
8u25
-
x86
-
windows_8
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
You can create a custom time zone implementation class by extending java.util.TimeZone. By the contract, the subclass must implement a few methods:
abstract int getOffset(int,int,int,int,int,int);
abstract int getRawOffset();
abstract boolean inDaylightTime(Date);
abstract void setRawOffset(int);
abstract boolean useDaylightTime();
Although, the interface above do not assume UTC offset or daylight saving amount is not changing time to time, a user can provide an implementation supporting historic UTC offset changes by int getOffset(int,int,int,int,int,int). However, there are two Java implementation problems.
1. The default implementation of TimeZone#getOffset(long date) does not use the abstract method - int getOffset(int,int,int,int,int,int). Therefore, when a different 'raw' offset was used in the past, or will be used in future, getOffset(long) always returns a result calculated from getRawOffset() and getDSTSavings(). Although a subclass implementation can provide TimeZone#getOffset(long date), the default implementation should use getOffset(int,int,int,int,int,int).
2. java.util.GregorianCalendar checks if a TimeZone instance is sun.util.calendar.TimZone or not, and if not, the offset field is calculated based on getRawOffset() / getDSTSavings(). Therefore, even a custom TimeZone implementation support different 'raw' offsets in the past or future, current 'raw' offset (getRawOffset()) value is used.
Use case:
A user may want to create a custom TimeZone instance from iCalendar VTIMEZONE component. iCalendr VTIMEZONE can support historic time zone rule changes.
Suggestions:
1) Add API TimeZone#getRawOffset(long) with the default implementation - return getRawOffset().
2) Add API TimeZone#getDSTSavings(long) with the default implementation - return getDSTSavings().
2) Update the default implementation of TimeZone#getOffset(long) to use #getRawOffset(long) #getDSTSavings(long) above along is existing #inDaylightTime(Date).
3) Gregorian calendar to use #getRawOffset(long) and #getDSTSavings(long), if not ZoneInfo.
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
You can create a custom time zone implementation class by extending java.util.TimeZone. By the contract, the subclass must implement a few methods:
abstract int getOffset(int,int,int,int,int,int);
abstract int getRawOffset();
abstract boolean inDaylightTime(Date);
abstract void setRawOffset(int);
abstract boolean useDaylightTime();
Although, the interface above do not assume UTC offset or daylight saving amount is not changing time to time, a user can provide an implementation supporting historic UTC offset changes by int getOffset(int,int,int,int,int,int). However, there are two Java implementation problems.
1. The default implementation of TimeZone#getOffset(long date) does not use the abstract method - int getOffset(int,int,int,int,int,int). Therefore, when a different 'raw' offset was used in the past, or will be used in future, getOffset(long) always returns a result calculated from getRawOffset() and getDSTSavings(). Although a subclass implementation can provide TimeZone#getOffset(long date), the default implementation should use getOffset(int,int,int,int,int,int).
2. java.util.GregorianCalendar checks if a TimeZone instance is sun.util.calendar.TimZone or not, and if not, the offset field is calculated based on getRawOffset() / getDSTSavings(). Therefore, even a custom TimeZone implementation support different 'raw' offsets in the past or future, current 'raw' offset (getRawOffset()) value is used.
Use case:
A user may want to create a custom TimeZone instance from iCalendar VTIMEZONE component. iCalendr VTIMEZONE can support historic time zone rule changes.
Suggestions:
1) Add API TimeZone#getRawOffset(long) with the default implementation - return getRawOffset().
2) Add API TimeZone#getDSTSavings(long) with the default implementation - return getDSTSavings().
2) Update the default implementation of TimeZone#getOffset(long) to use #getRawOffset(long) #getDSTSavings(long) above along is existing #inDaylightTime(Date).
3) Gregorian calendar to use #getRawOffset(long) and #getDSTSavings(long), if not ZoneInfo.
REPRODUCIBILITY :
This bug can be reproduced always.
- duplicates
-
JDK-6380023 (tz) API: some TimeZone methods can't deal with GMT offset and DST rule changes
- Open