<i18n dev> TimeZone#setRawOffset problem?
Yoshito Umaoka
y.umaoka at gmail.com
Mon Sep 15 19:24:09 UTC 2014
Hello,
I found some test cases in our project started failing after updating
JRE's tzdata version to 2014g. The test case creates a new TimeZone, and
modify the raw offset. I know it's ancient API before Java implemented
tz database, and I know the functionality is somewhat moot at this
point. However, it looks the problem was introduced recently - I thought
it worked OK a few months ago (but I'm not 100% sure).
Java version:
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
TZ database version: 2014g
Simple test code:
for (String id : TimeZone.getAvailableIDs()) {
TimeZone tz = TimeZone.getTimeZone(id);
int orgOffset = tz.getRawOffset();
// Update raw offset : + 30 minutes
int newOffset = orgOffset + 30*60*1000;
tz.setRawOffset(newOffset);
int actualOffset = tz.getRawOffset();
if (actualOffset != newOffset) {
System.out.println(id + " [org=" + orgOffset
+ ", new=" + newOffset
+ ", actual=" + actualOffset + "]");
}
}
Output:
Asia/Yakutsk [org=36000000, new=37800000, actual=41400000]
Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000]
Europe/Volgograd [org=14400000, new=16200000, actual=19800000]
Asia/Magadan [org=43200000, new=45000000, actual=52200000]
Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000]
Asia/Khandyga [org=36000000, new=37800000, actual=41400000]
Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000]
Asia/Vladivostok [org=39600000, new=41400000, actual=45000000]
Europe/Simferopol [org=14400000, new=16200000, actual=19800000]
Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000]
Asia/Omsk [org=25200000, new=27000000, actual=30600000]
Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000]
Asia/Sakhalin [org=39600000, new=41400000, actual=45000000]
Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000]
Asia/Chita [org=36000000, new=37800000, actual=45000000]
Asia/Irkutsk [org=32400000, new=34200000, actual=37800000]
Europe/Moscow [org=14400000, new=16200000, actual=19800000]
America/Grand_Turk [org=-18000000, new=-16200000, actual=-19800000]
W-SU [org=14400000, new=16200000, actual=19800000]
If my understanding is correct, the standard offset of these zones will
change later in this year.
Should I go ahead and file a bug?
-Yoshito
More information about the i18n-dev
mailing list