<i18n dev> TimeZone#setRawOffset problem?

Yoshito Umaoka y.umaoka at gmail.com
Mon Sep 15 19:24:09 UTC 2014


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;

             int actualOffset = tz.getRawOffset();

             if (actualOffset != newOffset) {
                 System.out.println(id + " [org=" + orgOffset
                         + ", new=" + newOffset
                         + ", actual=" + actualOffset + "]");


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?


More information about the i18n-dev mailing list