<i18n dev> RFR: 8159684: (tz) Support tzdata2016f

[Ramanand Patil]

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-dev at openjdk.java.net
Cc: core-libs-dev at 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.