<i18n dev> TimeZone#setRawOffset problem?

[Yoshito Umaoka]

Hi Aleksej,

 >The results you're observing looks correct.

I assume you actually meant:

- Java has a bug, returning the incorrect result with my simple test 
program.
- My observation of time zones causing the issue (the zones changing 
standard offset later in this year) is correct.

Right?
I know setting a different offset to a TimeZone created for an zone ID, 
is bogus. But, getRawOffset() should return what you set by 
setRawOffset(int) - which is not the case for these zones. For example, 
when you call tz.setRawOffset(37800000), then tz.getRawOffset() should 
return 37800000, not 41400000.

Yoshito

On 9/15/2014 4:04 PM, Aleksej Efimov wrote:
> 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
>>
>