Hello OpenJDK i18n dev team,
As you may already know, TZ database 2021b was released last week, and
it contains some drastic changes for pre-1970 rules. Multiple zones
sharing post 1970 rules were merged into one, and they were moved to
backward file. Pre-1970 rules used for these merged zones
Hello Sato-san,
As you know, tz database 2018a flipped Europe/Dublin winter/summer time
rules. There were many messages posted in the tz mailing list, and Paul
Eggert decided to revert the change in tz database 2018c. For future
releases, it looks he want to add a zic build option to swap the
Hi Sato-san,
I filed a bug ID: 9051183.
Thanks,
Yoshito
On 10/13/2017 1:57 PM, Naoto Sato wrote:
Hi Umaoka-san,
Yeah, that looks like a bug to me. Can you please file it, as I wasn't
aware of it being reported.
Naoto
On 10/13/17 10:39 AM, Yoshito Umaoka wrote:
Hello,
I recei
Hello,
I received a problem report from an ICU4J consumer who uses ICU4J Locale SPI
module.
ICU NumberFormatProvider returns a class -
com.ibm.icu.impl.jdkadapter.NumberFormatICU which extends
java.text.NumberFormat.
The ICU4J locale SPI user found the ICU provider causes an issue when he uses
On 1/6/2017 4:11 PM, Naoto Sato wrote:
Opened a new issue for the latter:
https://bugs.openjdk.java.net/browse/JDK-8172365
Naoto
Thank you, Sato-san.
-Yoshito
On 1/6/2017 12:52 PM, Naoto Sato wrote:
Hi Yoshito,
On 1/6/17 6:52 AM, Yoshito Umaoka wrote:
i18n-dev team
What is your plan for a series of LocaleServiceProvider SPIs? Is it
possible to change the implementation of LocaleServiceProvider and
ResourceBundleControlProvider not to use Java&#
On 1/6/2017 4:47 AM, Alan Bateman wrote:
On 06/01/2017 09:13, Yoshito Umaoka wrote:
Yes. See
https://github.com/IBM-Bluemix/gp-java-client#using-resourcebundlecontrolprovider-spi-java-8-or-later
The jar file contains java.util.spi.ResourceBundleControlProvider
[https://github.com/IBM
On 1/6/2017 3:36 AM, Alan Bateman wrote:
On 05/01/2017 22:44, Yoshito Umaoka wrote:
Wow.. We utilize ResourceBundleControlProvider SPI and our software
heavily depends on it
[https://github.com/IBM-Bluemix/gp-java-client]. This is only the way
to inject custom resource loading logic
On 12/19/2016 11:28 AM, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8171189
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8171189/webrev.00/
The said SPI utilizes the Java extension mechanism which is now
l affect the performance. I don't see
anything wrong to check if foo is null or not in clone(), since it's a
private property to the provider.
Naoto
On 6/5/15 8:31 AM, Yoshito Umaoka wrote:
Hi folks,
ICU4J implements Java locale service provider interface. I recently
received a
On 6/5/2015 11:31 AM, Yoshito Umaoka wrote:
@Override
public Object clone() {
MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone();
mdfs.foo = this.foo.clone();
}
Minor correction - "return mdfs;" was missing in the pseudo code above.
-Yoshito
Hi folks,
ICU4J implements Java locale service provider interface. I recently
received a problem report from our customer. When they upgraded Java
version to 8, the provider implementation stopped working because of NPE
thrown by our custom DateFormatSymbols subclass. I dug into the problem
a
Hello,
Does Java i18n-dev team own java.net.IDN implementation? The current
implementation is based on already deprecated IDNA2003. JDK should
support IDNA2008.
I found JDK-6988055
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6988055], but it
looks there is no plan yet.
-Yoshito
ign flaw of java.util.TimeZone.
Since we now have the java.time API, I guess JDK-6380023 doesn't have
any high priority (unless it gets escalated by someone).
Regards,
Masayoshi
On 10/18/2014 5:43 AM, Yoshito Umaoka wrote:
Dear Java i18n team,
I was looking at recent Russian time zone cha
Dear Java i18n team,
I was looking at recent Russian time zone changes and noticed a design
issue in JDK. I think I knew this issue, but I forgot about this until
recently. The problem is - Java does not support user defined custom
TimeZone implementation properly.
java.util.TimeZone is quit
In July, Okutsu-san sent a review request for JDK-8048123.
I found this is very useful as temporary workaround until new Java patch
embedding the new era.
However, I think I found one issue. If you use java.util.Calendar, with
locale ja-JP-u-ca-japanese, it seems to work as you expect. However
On 9/15/2014 5:59 PM, Aleksej Efimov wrote:
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 T
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 creat
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
On 4/25/2013 5:21 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013086
The fix is to complement the missing display names with the provided
ones for TimeZoneNameProvider implementations.
http://cr.openjdk.java.n
Great work. I spent some time reviewing the implementation last couple
of weeks.
So far, it looks good.
I have one suggestion -
http://cr.openjdk.java.net/~naoto/6336885/webrev.03/src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java.html
- line 49-
49 private static final Str
I thought Windows XP might (internally) use the Dynamic DST data in
the Time Zones registry for supporting any DST rule changes, because
Dynamic DST was introduced for the US DST rule change IIRC. But as far
as I tested, XP seems to ignore Dynamic DST data. If that's the case,
your proposed f
a.net/~littlee/OJDK-548/webrev.01
<http://cr.openjdk.java.net/%7Elittlee/OJDK-548/webrev.01>
On 04/11/2012 04:00 AM, Yoshito Umaoka wrote:
I'm wondering if caching index matched last time (per
DateFormatSymbols instance) is sufficient, instead of keeping
multiple results in a hash map.
I guess majo
I'm wondering if caching index matched last time (per DateFormatSymbols
instance) is sufficient, instead of keeping multiple results in a hash map.
I guess majority of use cases repeatedly refer the index of the zone
used by SimpleDateFormat.
-Yoshito
On 4/9/2012 10:46 AM, Masayoshi Okutsu wro
Thanks of all of you.
This problem was introduced by the contribution from ICU project, and
I'm responsible to the specific code.
-Yoshito
On 10/6/2011 5:59 PM, Naoto Sato wrote:
Hi David,
Thank you for the quick look and the fix!
Naoto
On 10/6/11 10:09 AM, David Holmes wrote:
Hi Chris,
Last week, we agreed to change the meeting time starting today from 5pm
PT to 2pm PT.
Unfortunately, I have a doctor appointment at 1:15pm PT today. So I'll
keep the current schedule (5pm PT) for today's call. I'll update the
meeting time starting next week.
Thanks,
Yoshito
this problem?
Thanks,
Yoshito Umaoka
by the ICU project
(http://icu-project.org/) in C++ and Java. This is the API
specification of the Java implementation, including the rule syntax
definitions -
http://www.icu-project.org/apiref/icu4j/com/ibm/icu/text/RuleBasedNumberFormat.html
-Yoshito Umaoka
samuel jawahar wrote:
Hello
re in ICU, but not exposed yet.
Yoshito Umaoka (ICU Project)
sets is null
or too short.
public void getOffset(long date, int[] offsets) {
if (inDaylightTime(new Date(date)) {
offsets[1] = getDSTSavings();
offsets[0] = getOffset(date) - offsets[1];
} else {
offsets[0] = getOffset(date);
offsets[1] = 0;
}
}
Yoshito Umaoka (ICU Project)
DaylightTime(new Date(date)) {
offsets[1] = getDSTSavings();
offsets[0] = getOffset(date) - offsets[1];
} else {
offsets[0] = getOffset(date);
offsets[1] = 0;
}
}
I propose to add this method in java.util.TimeZone and use it in JDK
Calendar implementation. Any opinions?
Yoshito Umaoka (ICU Project)
rting the locale data from CLDR into JDK will benefit
both JDK development and Java users.
Yoshito Umaoka (ICU Project)
32 matches
Mail list logo
