[tz] Add option to act like global-tz

Stephen Colebourne scolebourne at joda.org
Thu Aug 4 00:01:28 UTC 2022


On Wed, 27 Jul 2022 at 19:10, Paul Eggert via tz <tz at iana.org> wrote:
> On 7/27/22 01:47, Stephen Colebourne via tz wrote:
> > Can you clarify what is generated?
> > the tooling chains
> > that global-tz supports need the *source* files (africa, europe,
> > northamerica...) to contain the data
>
> You can get that by using the tailored_tarballs target added recently.
> For example, this shell command:
>
>    make DATAFORM=rearguard \
>      PACKRATDATA=backzone PACKRATLIST=zone.tab tailored_tarballs
>
> generates a tarball that should be suitable for the toolchains you
> mention.

Thanks. The output being generated here is correct for some downstream
toolchains AFAICT.

Observations:

1) Some of the toolchains (ThreeTen-BP at least) depend on the
`leapseconds` file, so can that be added please.

2) The generated tarball places all data in the etcetera file, rather
than in africa/asia etc. This may cause problems for downstream users
that wish to only package some files. I suspect that group of people
is small, nevertheless it is worth noting that the generated tarball
is not equivalent.

3) The generated tarball omits other files like zone.tab, iso3166.tab,
backzone, backward and so on.

In effect the contents are significantly less functional than those of
global-tz. ie. global-tz goes to significant lengths to simulate
exactly what iana-tz would have looked like if the pre-1970 merges had
never happened. The output of global-tz is therefore fully compatible
with all toolchains, no matter what they do with the data.


Actions/Questions:

As a minimum we need to add the `leapseconds` file to the generated tarball.

Is it practical to keep the various files separate? Or to include more
files? Right now it doesn't really feel like a compatible tzdata
tarball as it has quite different content. My concern here is non-Java
downstream projects that wish to avoid the merges - do they have what
they need?

(ie. I would prefer not to maintain global-tz, and it will need a good
few hours work to undo the latest European merges, but I would need to
be sure that all potential use cases are covered.)

thanks
Stephen


More information about the tz mailing list