<i18n dev> TimeZone#setRawOffset problem?
Yoshito Umaoka
y.umaoka at gmail.com
Mon Sep 15 20:45:03 UTC 2014
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
>>
>
More information about the i18n-dev
mailing list