On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar
wrote:
>> Looks good. I think we should release-note the removal of the
>> "US/Pacific-New" Link on the off chance that some
>> production/testing system is looking for such a zone.
>
> Thanks for the review everyone, I have added a re
On 27/04/2020 19:19, Kiran Ravikumar wrote:
> Hi Martin and Andrew,
>
>
> Thanks for the review and providing a direction towards updating the
> translations.
>
>
> Here is an updated webrev with the changes:
>
> http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
>
>
> All associated
On 27/04/2020 12:13, Kiran Ravikumar wrote:
> Hello All,
>
>
> Please review the patch for tzdata2020a integration into jdk.
>
> Release details can be found here:
>
> http://mm.icann.org/pipermail/tz-announce/2020-April/58.html
>
>
> Webrev: http://cr.openjdk.java.net/~kravikumar/8243
On 11/07/2019 07:37, Dmitry Cherepanov wrote:
> Looks good to me.
>
> One suggestion: does it make sense to include additional change in
> ZoneInfoFile.java to address the comment [1] in 8u too, it was fixed in the
> final patch for jdk/jdk13 [2].
>
> Thanks,
>
> Dmitry
>
> [1]
> https://
Bug: https://bugs.openjdk.java.net/browse/JDK-8224560
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.01/
This is the 8u version of the patch proposed in [0]. It mostly applies
as is, but the CLDRConverter.java changes can be dropped (no JDK-8189784
and friends in 8u). The chan
On 05/07/2019 15:16, Ramanand Patil wrote:
> Hi all,
> Please review the patch for tzdata2019a integration into jdk project.
> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
> https://bugs.openjdk.java.net/browse/JDK-8225580
On 05/07/2019 17:52, Severin Gehwolf wrote:
> Hi Andrew,
>
> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
>>
>>
On 28/06/2019 22:20, Hohensee, Paul wrote:
> I'm ok with it: more tests are a good thing.
>
> Thanks,
>
> Paul
Thanks, Paul. Pushed:
https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/66a0979b0557
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key:
Bug: https://bugs.openjdk.java.net/browse/JDK-8031145 (not accessible)
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8031145/webrev.01/
This changeset adds a slew of tests for outputting internationalised
data. This is a pre-requisite for "8210153: localized currency symbol of
VES" which up
Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
OpenJDK 8u uses an older version of the CLDR data to 9, and is thus
missing a number of locale data files updated by the original version of
8218781. Thus, some chunks are
On 15/04/2019 18:47, Andrew Haley wrote:
> On 4/13/19 3:03 AM, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202088
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk7/8202088/webrev.01/
>>
>> This is the backport of the J
Bug: https://bugs.openjdk.java.net/browse/JDK-8202088
Webrev: https://cr.openjdk.java.net/~andrew/openjdk7/8202088/webrev.01/
This is the backport of the Japanese new era placeholder implementation
to OpenJDK 7u. It is significantly smaller than the versions for 8u &
11u, as 7u does not contain th
Masayoshi
>
> On 1/8/2010 2:13 AM, Andrew John Hughes wrote:
>>
>> Bug 6584033 actually fixes two issues, the second relating to the
>> interaction between the timezone setting, the security manager and
>> signed jars: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3
Bug 6584033 actually fixes two issues, the second relating to the
interaction between the timezone setting, the security manager and
signed jars: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=381
It was fixed in OpenJDK7 b22, but there is no testcase to ensure this
doesn't regress. Mark W
2009/12/11 Martin Buchholz :
> On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes
> wrote:
>> 2009/12/10 Joseph D. Darcy :
>> I added the fixes mentioned and tried to push. I was greeted with this:
>>
>> remote:
>> remote: test/java/util/TimeZone/TimeZoneDatePer
2009/12/10 Joseph D. Darcy :
> Andrew John Hughes wrote:
>>
>> 2009/12/9 Joseph D. Darcy :
>>
>>>
>>> Andrew John Hughes wrote:
>>>
>>>>
>>>> 2009/12/8 Andrew John Hughes :
>>>>
>>>>
>>>>
2009/12/9 Joseph D. Darcy :
> Andrew John Hughes wrote:
>>
>> 2009/12/8 Andrew John Hughes :
>>
>>>
>>> 2009/12/8 Joseph D. Darcy :
>>>
>>>>
>>>> Andrew John Hughes wrote:
>>>>
>>&g
2009/12/3 Bill Tims (RSI) :
> Andrew/Masayoshi
>
> 1) I installed openjdk-6-jdk(I only had the jre-lib installed before)
> and reran the following code. This didn't seem to make any difference.
> 2) Andrew's last email references the tzdata-java package.
> After the run with the jd
2009/12/3 Andrew John Hughes :
> 2009/12/2 Bill Tims (RSI) :
>> Andrew
>>
>> I've signed up and hopefully this will show up on the list.
>> The program is attached. I ran it, with test2(), with strace and grep'd
>> for javazi and got:
>>
&g
e...so far.
>
So OpenJDK6 is the one that's wrong? It may be that America/Chicago
should be being used, as Masayoshi says, or could just be outdated
timezone data in OpenJDK6.
> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX 78751
> 512-275-0344
&g
et/pipermail/i18n-dev/2009-August/000136.html
(it's debatable whether such a fix is needed over just a simple symlink).
> Bill
>
> Bill Tims
> Renaissance Systems, Inc.
> 5426 Guadalupe, Suite 100
> Austin, TX 78751
> 512-275-0344
>
>
> -Original Message-
2009/12/1 Masayoshi Okutsu :
> What is the time zone ID you are using?
>
> Thanks,
> Masayoshi
>
> On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
>>
>> From what I can find, this appears to be the right place to post this, if
>> I'm wrong I would appreciate a pointer to the proper location.
>> The d
2009/8/29 Mark Wielaard :
> Hi,
>
> I was debugging the following bug report:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=377
> "TimeZone.getOffset() fails for some TZ"
> The issue is caused because there is a start rule in the Asia/Amman
> timezone that starts at the end of a day. Simp
When distros update their timezone data, the data used by OpenJDK also
needs to be updated. At present, this is difficult as OpenJDK uses a
hardcoded path (${java.home}/jre/lib/zi} for timezone data with no
option to override it.
A bug was filed for this issue back in 2007 and there was some
disc
2009/8/25 Yuri Nesterenko :
> Hi Andrew,
>
> i18n, I think, do push now to the swing forest.
> I'm responsible for integrations for these groups, and I do
> sync the swing forest only, not i18n.
>
> Thanks,
> -Yuri
>
>
> Andrew John Hughes wrote:
>>
>
I was just about to check out the i18n forest as a precursor to
submitting a patch, but it seems the forest is massively outdated; the
latest build drop it includes is b25 which was just after the hg repos
were created!
What's going on here? Is there no i18n work being done?
I presume any patch w
26 matches
Mail list logo
