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

[Andrew John Hughes]

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 :)

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. 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 :)

P.S. I agree it would be nice if tzupdater was open sourced...

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew