<i18n dev> TimeZone#setRawOffset problem?

[Aleksej Efimov]

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
>