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.uma...@gmail.com<br>To: aleksej.efi...@oracle.com<br>Cc: i18n-dev@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.4010...@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.6010...@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>
