Hi Masayoshi,
The reason for adding bugId(8159684) to TimeZoneTest.java was, it actually
tests the major change in the releases tzdata2016e and tzdata2016f.
tzdata2016e: "Africa/Cairo observes DST in 2016 from July 7 to the end of
October."
tzdata201f: The Egyptian government changed its mind on short notice, and
Africa/Cairo will not introduce DST starting 2016-07-07 after all.
After integrating, tzdata2016e, TimeZoneTest.java was failing because at line
no. 123 DST was false which should be true. (new ZoneDescriptor("ART", 120,
false))
And integrating tzdata2016f has again made the DST false in the test case.
Since the bug covers both the changes, I kept the bugID in the test case.
Please let me know if I still need to remove the bugID from test case.
Regards,
Ramanand.
-----Original Message-----
From: Masayoshi Okutsu
Sent: Wednesday, July 13, 2016 12:14 PM
To: Ramanand Patil; i18n-...@openjdk.java.net
Cc: core-libs-dev@openjdk.java.net
Subject: Re: <i18n dev> RFR: 8159684: (tz) Support tzdata2016f
I don't think it's appropriate to add 8159684 to TimeZoneTest.java which
doesn't test the data changes of 2016e/f at all. I think there should be a time
zone data test in java.time to confirm the tzdata changes.
Otherwise, the changes look good to me.
Thanks,
Masayoshi
On 7/12/2016 6:27 PM, Ramanand Patil wrote:
> Hi all,
>
> Please review the latest TZDATA integration (tzdata2016f) to JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8159684
> Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/
>
> All the TimeZone related tests are passed after this integration.
>
> Regards,
> Ramanand.
