Hello Yoshito,
Correct - the standard offsets of these timezones will change later this
year, for example "Asia/Yakutsk" (it's a part of tz db that will be soon
in JDK7 [1], and the one you had after running a tzupdater):
2631 Zone Asia/Yakutsk 8:38:58 - LMT 1919 Dec 15
2632 8:00 - YAKT 1930 Jun 21 # Yakutsk Time
2633 9:00 Russia YAK%sT 1991 Mar 31 2:00s
2634 8:00 Russia YAK%sT 1992 Jan 19 2:00s
2635 9:00 Russia YAK%sT 2011 Mar 27 2:00s
*2636 10:00 - YAKT 2014 Oct 26 2:00s*
2637 9:00 - YAKT
Same picture for "Asia/Magadan":
2717 Zone Asia/Magadan 10:03:12 - LMT 1924 May 2
2718 10:00 - MAGT 1930 Jun 21 # Magadan Time
2719 11:00 Russia MAG%sT 1991 Mar 31 2:00s
2720 10:00 Russia MAG%sT 1992 Jan 19 2:00s
2721 11:00 Russia MAG%sT 2011 Mar 27 2:00s
*2722 12:00 - MAGT 2014 Oct 26 2:00s
*
And "Europe/Moscow" and etc:
2335 Zone Europe/Moscow 2:30:17 - LMT 1880
2336 2:30:17 - MMT 1916 Jul 3 # Moscow Mean
Time
2337 2:31:19 Russia %s 1919 Jul 1 2:00
2338 3:00 Russia %s 1921 Oct
2339 3:00 Russia MSK/MSD 1922 Oct
2340 2:00 - EET 1930 Jun 21
2341 3:00 Russia MSK/MSD 1991 Mar 31 2:00s
2342 2:00 Russia EE%sT 1992 Jan 19 2:00s
2343 3:00 Russia MSK/MSD 2011 Mar 27 2:00s
*2344 4:00 - MSK 2014 Oct 26 2:00s*
2345 3:00 - MSK
The results you're observing looks correct.
Best Regards,
Aleksej
[1]
http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html
On 09/15/2014 11:24 PM, Yoshito Umaoka wrote:
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
