<i18n dev> RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[Ramanand Patil]

Hi Naoto and Martin,
Thank you very much for your reviews.

Hi Martin,
Naoto is correct, the jdk build will fail for the update releases when using vanguard format, since the fix from JDK-8212970 is not yet backported.
Since, jdk14 has this fix, my current patch uses vanguard format tzdata.

I am planning to backport JDK-8212970 along with the tzdata2019c integration into the update releases, if there are no major issues. I have already seen the 11u backport request from Christoph for-8212970.

Regards,
Ramanand.

> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, September 17, 2019 11:25 PM
> To: Martin Buchholz <martinrb at google.com>
> Cc: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; i18n-dev <i18n-dev at openjdk.java.net>
> Subject: Re: <i18n dev> RFR: 8231098: (tz) Upgrade time-zone data to
> tzdata2019c
> 
> On 9/17/19 10:14 AM, Martin Buchholz wrote:
> >
> >
> > On Tue, Sep 17, 2019 at 9:45 AM <naoto.sato at oracle.com
> > <mailto:naoto.sato at oracle.com>> wrote:
> >
> >     +1
> >
> >     On 9/17/19 8:29 AM, Martin Buchholz wrote:
> >      > Looks good to me.
> >      > At Google we also integrated tzdata2019c, and it was uneventful
> >     (good!).
> >      > But we're still using rearguard format.
> >      > The vanguard/rearguard distinction is a source of errors, so it
> >     should be
> >      > made clear what format is being used to import the files.
> >      > If you have a script to update the jdk sources, perhaps it should be
> >      > checked in to openjdk?
> >      > If these files are in vanguard format, is there a trap for those
> >     of us
> >      > doing backports to jdks that only support rearguard?
> >
> >     Can't think of any off the top of my head, Martin. The build tool
> >
> >
> > Which build tool? TzdbZoneRulesCompiler?
> 
> Yes.
> 
> >
> >     internally converts vanguard data into rearguard compatible, by
> >     adjusting the standard offsets, and build into tzdb.dat (which should
> >     even be compatible to prior JDK runtimes).
> >
> >
> > So ... a change like this one is created by copying selected vanguard
> > format files from the tzdata source distribution into openjdk, and
> > then TzdbZoneRulesCompiler converts to rearguard format internally?
> > At Google, we chose to run tzdata's own tool to convert to rearguard
> > format and then check in those data files into the jdk source tree.
> 
> The tool will not convert the file format to rearguard. Read the vanguard
> format file, then converts the data into tzdb.dat that can be recognized by
> prior runtimes.
> 
> >
> > I worry that when other engineers backport to older releases, if only
> > the data files are copied, then conversion to rearguard format will
> > not happen, with bad results.
> 
> If an engineer only backports the vanguard files into older releases (before
> the vanguard support), I don't think the JDK build will succeed.
> Build will fail on creating tzdb.dat file.
> 
> Naoto