[RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b

[Martin Buchholz]

On Wed, Sep 25, 2019 at 9:15 AM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

>
>
> On 25/09/2019 16:47, Martin Buchholz wrote:
> > At Google we try to keep our internal JDK's tzdata updated within a week
> > or so of an IANA tzdata release,
> > so we are already using tzdata2019c, and I recommend backporting that
> > for your jdk8u (in rearguard!).
> > But there are also risks when simply replacing upstream tzdata files,
> > e.g. we've run into
> > https://bugs.openjdk.java.net/browse/JDK-8226704
> > <https://bugs.openjdk.java.net/browse/JDK-8226704?filter=25118>
> > but tzdata2019c looks pitfall-free.
>
> I did consider whether we should do tzdata2019c too, after seeing it was
> out. Doing so would need an OpenJDK bug, so I tend to work for Oracle's
> team to do that. It seems they have:
>
> https://bugs.openjdk.java.net/browse/JDK-8231098
>
> If I backport that (in rearguard), would you be willing to do a quick
> review? I'd prefer not to hassle Aleksey for one twice in one day :)
>

Sure.


> We do something similar in RHEL, in that we generate the tzdata as part
> of system tzdata updates rather than relying on the JDK copy. So when
> the system gets tzdata2019c, all JDK versions do too.
>
> This does mean we've run into the exact same problem you mention and has
> made us wary of that being the right approach.


The RHEL and tzupdater both take the approach that tzdata files can
"simply" be updated.
But in the real world this can't actually work reliably because tzdata
releases are incomplete - ICU and CLDR are independent projects that
produce additional metadata (like translating names of cities in Kazakhstan
into French).  With my Google hat on I think I have 6 upstreams - IANA,
ICU, CLDR, OpenJDK head, jdk-updates, and my Linux distro provider.
Vanguard/Rearguard is an additional problem.  We can't get it right, but we
muddle through.


> Do you have any sanity
> tests you run following an update? I'm thinking along the lines of
> something we could quickly run at the end of a package build cycle
> rather than the whole TCK :)
>

Well, you have to run all the tests on any release candidate!

For tzdata, one should only need to run all the java.time jtreg tests.
Not sure if there's a regression test to catch
https://bugs.openjdk.java.net/browse/JDK-8226704