On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move the LocaleDataMetaInfo of CLDR from
java.
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move the LocaleDataMetaInfo of CLDR from
java.base module to jdk.localedata module, alon
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 histo
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 k
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/Yakutsk8:38:58 - LMT 1919 Dec 15
2632
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
