Hi Umaoka-san,
Thank you for your proposal. Yes, the TimeZone class has some built-in
assumptions which cause many problems. I had been planning to introduce
some methods, one of which is very similar to your proposal, mainly for
fixing the disambiguation problem during the standard-daylight transitions.
I still want to fix it in JDK7, but I'm not sure if I can have time to
do so at this point.
Thanks,
Masayoshi
On 8/13/2008 6:59 AM, Yoshito Umaoka wrote:
Hello all,
I'm experiencing a problem for setting my own TimeZone implementation
as system default time zone. After some investigation, I think this
problem is caused by the lack of API in java.util.TimeZone.
When TimeZone was introduced in JDK 1.1, it did not support historical
GMT offsets/daylight saving time rules. So "raw" offset is always
same at anytime. When JDK 1.4 implemented historic rules, APIs were
not much changed.
With TimeZone methods, you can get GMT offset at the specified time.
You can also see if the specified time is in daylight saving time or
not. HOWEVER, you have no way to know "raw" GMT offset and daylight
saving amount. This is usually not a problem, because you can still
get the GMT offset (raw + dstsaving). The problem shows up when
TimeZone is used by Calendar.
Calendar has two fields - ZONE_OFFSET and DST_OFFSET. Calendar
implementation obviously needs to get the raw GMT offset and the
daylight saving amount for setting these fields. However, there are
no such APIs in TimeZone class. Calendar implementation calls my
TimeZone subclass's getRawOffset()/getDSTSavings() instead.
getRawOffset() and getDSTSavings() are somewhat broken when the
historic rule support was introduced. The raw GMT offset and the
daylight saving amount could change time to time. But these APIs do
not take any arguments specifying date.
Calendar code calls another method supporting historic raw/dst amount
changes when the implementation class of TimeZone is JDK's own private
one. I think such API should be added in TimeZone as a public API, so
Java users can implement their own TimeZone subclasses which work well
with Calendar.
In our project (ICU4J), we added an API below in our TimeZone class -
public void getOffset(long date, boolean local, int[] offsets)
This API returns the raw offset in offsets[0] and the daylight saving
amount in offsets[1] at the specified time. I do not think the second
argument (specifying whether 'date' is local wall time or GMT) is
necessary. I think JDK TimeZone also needs such method to resolve
Calendar field calculation problem above. The default implementation
would be -
public void getOffset(long date, int[] offsets) {
if (offsets == null || offsets.length < 2) {
offsets = new int[2];
}
if (inDaylightTime(new Date(date)) {
offsets[1] = getDSTSavings();
offsets[0] = getOffset(date) - offsets[1];
} else {
offsets[0] = getOffset(date);
offsets[1] = 0;
}
}
I propose to add this method in java.util.TimeZone and use it in JDK
Calendar implementation. Any opinions?
Yoshito Umaoka (ICU Project)
