<i18n dev> TimeZone#setRawOffset problem?
Aleksej Efimov
aleksej.efimov at oracle.com
Mon Sep 15 21:59:24 UTC 2014
Yoshito,
I can explain such behavior only by this part of javadoc + some calculations:
Let's select the Asia/Yakutsk (please, refer to tzdb rules in previous e-mail) as an example. The 'setRawOffset' javadoc [1] says the following:
"If an underlying TimeZone implementation subclass supports historical GMT offset changes, the specified GMT offset is set as the latest GMT offset and the difference from the known latest GMT offset value is used to adjust all historical GMT offset values."
The latest known GMT offset is: 9:00 = 32400 (let's count in seconds)
New raw offset value (the value set by your test program): 37800
The difference from the known latest GMT offset value: 37800 - 32400 = 5400
Current DST offset (10:00 = 36000 ) is adjusted with this constant: 36000 + 5400 = 41400
Please, note that the 37800 is set as a last GMT offset and it will take effect only on "2014 Oct 26". Other historical offsets will be corrected with difference between latest tzdb offset and new offset value = 5400.
I think everything works as expected and not sure if it is a JDK bug, maybe unclear documentation or something else.
-Aleksej
[1] http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#setRawOffset(int)
<br>----- Original Message -----<br>From: y.umaoka at gmail.com<br>To: aleksej.efimov at oracle.com<br>Cc: i18n-dev at openjdk.java.net<br>Sent: Tuesday, September 16, 2014 12:45:21 AM GMT +04:00 Abu Dhabi / Muscat<br>Subject: Re: <i18n dev> TimeZone#setRawOffset problem?<br><br><html>
<head>
</head>
<div>
<div class="moz-cite-prefix">Hi Aleksej,<br>
<br>
>The results you're observing looks correct.<br>
<br>
I assume you actually meant:<br>
<br>
- Java has a bug, returning the incorrect result with my simple
test program.<br>
- My observation of time zones causing the issue (the zones
changing standard offset later in this year) is correct.<br>
<br>
Right?<br>
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.<br>
<br>
Yoshito<br>
<br>
On 9/15/2014 4:04 PM, Aleksej Efimov wrote:<br>
</div>
<blockquote cite="mid:54174660.4010100 at oracle.com">
<div class="moz-cite-prefix">Hello Yoshito,<br>
<br>
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):<br>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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
<b>2636 10:00 - YAKT 2014 Oct 26 2:00s</b>
2637 9:00 - YAKT</pre>
Same picture for "Asia/Magadan":<br>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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
<b>2722 12:00 - MAGT 2014 Oct 26 2:00s
</b></pre>
And "Europe/Moscow" and etc: <br>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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
<b>2344 4:00 - MSK 2014 Oct 26 2:00s</b>
2345 3:00 - MSK</pre>
<br>
The results you're observing looks correct.<br>
<br>
Best Regards,<br>
Aleksej<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html" target="_blank">http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html</a><br>
<br>
On 09/15/2014 11:24 PM, Yoshito Umaoka wrote:<br>
</div>
<blockquote cite="mid:54173CD9.6010409 at gmail.com">Hello,
<br>
<br>
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). <br>
<br>
Java version: <br>
<br>
java version "1.7.0_67" <br>
Java(TM) SE Runtime Environment (build 1.7.0_67-b01) <br>
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
<br>
<br>
TZ database version: 2014g <br>
<br>
Simple test code: <br>
<br>
for (String id : TimeZone.getAvailableIDs()) { <br>
TimeZone tz = TimeZone.getTimeZone(id); <br>
<br>
int orgOffset = tz.getRawOffset(); <br>
<br>
// Update raw offset : + 30 minutes <br>
int newOffset = orgOffset + 30*60*1000; <br>
tz.setRawOffset(newOffset); <br>
<br>
int actualOffset = tz.getRawOffset(); <br>
<br>
if (actualOffset != newOffset) { <br>
System.out.println(id + " [org=" + orgOffset <br>
+ ", new=" + newOffset <br>
+ ", actual=" + actualOffset + "]"); <br>
} <br>
} <br>
<br>
Output: <br>
<br>
Asia/Yakutsk [org=36000000, new=37800000, actual=41400000] <br>
Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000]
<br>
Europe/Volgograd [org=14400000, new=16200000, actual=19800000] <br>
Asia/Magadan [org=43200000, new=45000000, actual=52200000] <br>
Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000]
<br>
Asia/Khandyga [org=36000000, new=37800000, actual=41400000] <br>
Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000]
<br>
Asia/Vladivostok [org=39600000, new=41400000, actual=45000000] <br>
Europe/Simferopol [org=14400000, new=16200000, actual=19800000]
<br>
Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000] <br>
Asia/Omsk [org=25200000, new=27000000, actual=30600000] <br>
Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000] <br>
Asia/Sakhalin [org=39600000, new=41400000, actual=45000000] <br>
Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000] <br>
Asia/Chita [org=36000000, new=37800000, actual=45000000] <br>
Asia/Irkutsk [org=32400000, new=34200000, actual=37800000] <br>
Europe/Moscow [org=14400000, new=16200000, actual=19800000] <br>
America/Grand_Turk [org=-18000000, new=-16200000,
actual=-19800000] <br>
W-SU [org=14400000, new=16200000, actual=19800000] <br>
<br>
<br>
If my understanding is correct, the standard offset of these
zones will change later in this year. <br>
<br>
Should I go ahead and file a bug? <br>
<br>
-Yoshito <br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div>
</html>
More information about the i18n-dev
mailing list