How should we handle tzdata/zoneinfo

[ocefpaf]

For now I commented out the tzdata package and the new datetime functionality won't work in our RC release. See dd8de19

We should figure out a way to provide a python tzdata package for Windows and Linux/macOS for testing avoiding the circular dependencies or complex builds.

The alternatives are:

• Python a special case py39 without it and then build tzdata
• Create a non-python tzdata package that would not require python at install time
• Don't test it and let users rely on whatever the system provides (this will leave Windows users hanging though!)

xref.: #389

[mbargull]

I took a look at this today.

The Python tzdata package is just

• the zoneinfo/ directory from the time zone database,
• with __init__.py files added to make every subdirectory a Python package,
• and an additional zones file as a performance optimization, apparently.
  (See zoneinfo/_tzpath.py#L118-L127 and zoneinfo/_tzpath.py#L156-L160.)

We can set a TZPATH at compile time via https://docs.python.org/3.9/library/zoneinfo.html#zoneinfo-data-compile-time-config.
Since we (conda-forge) can independently of the system keep our time zone database up to date, it makes sense to create a noarch: generic package that has only ${PREFIX}/share/zoneinfo (w/o the binaries from tzcode). Then we can depend on that package and set TZPATH to ${PREFIX}/share/zoneinfo for all platforms.

If we have that in place, the Python package is more or less redundant for conda-forge, IMHO. People could still install it if they care about the zones file.

---

One issue is the naming of the package though.

• The obvious choice of name for such noarch: generic would be tzdata.
• But that name was assigned on conda-forge to the new Python package.
• Anaconda does not have a tzdata package yet. To get a better UX, we should coordinate with Anaconda on the naming.
• If @conda-forge/core does not find it problematic, my preference would be to rename conda-forge::tzdata to conda-forge::python-tzdata and reuse the tzdata name for the actual tzdata. https://anaconda.org/conda-forge/tzdata/files has a comparatively low download count, was added 4 months ago and has only one build. If we can go that route, we should do it timely.
• Alternative names would be tz, zoneinfo, tz-database, zoneinfo-database, time-zone-database.
• (FYI, we have a package tzcode that also has the program part of tzdata, not noarch, naturally.)
• (FYI, there are other packages on conda-forge that, i.e., pytz, pytzdata, tzlocal`, but those are different packages.)

(If we wanted to go full-on non-vendoring/one-source-of-truth, we could also make the Python tzdata package depend on the actual tzdata one -- e.g., via some resource reading shim which would be easy enough to do. But again, the Python package is rather unimportant for us, IMO.)

[beckermr]

Quick note: We had also discussed using these files for the system root packages on linux instead of the older Cos6/Cos7 ones.

[jjhelmus]

@mbargull The proposed noarch: generic package and configuring python to use ${PREFIX}/share/zoneinfo (I think via the --with-tzpath option) seems like a good solution to me.

As for a name, I also favor tzdata, with the existing package being re-named python-tzdata. (or py-tzdata) tzdata is the named used by most Linux distributions.

One question is if the time zone database files in the PyPI tzdata package should be used as a source for the noarch: generic package or if a different upstream source, such as https://www.iana.org/time-zones, should be used?

[mingwandroid]

We should try to move quickly on this since 3.9.0 is released. The PR is nearly ready for python, excluding this stuff. Is anyone working on it?

[mbargull]

As for a name, I also favor tzdata, with the existing package being re-named python-tzdata. (or py-tzdata) tzdata is the named used by most Linux distributions.

Okay, I'll go with python-tzdata then. (Not choosing py-tzdata because it's too close to the existing pytzdata package.)

One question is if the time zone database files in the PyPI tzdata package should be used as a source for the noarch: generic package or if a different upstream source, such as https://www.iana.org/time-zones, should be used?

We should use the upstream source. https://github.com/python/tzdata/blob/2020.1/update.py#L87 is the core of what the Python package does, which is just running upstream's Makefile.

We should try to move quickly on this since 3.9.0 is released.

IMHO, it wouldn't be terrible if the first build doesn't include it (new module and all).

The PR is nearly ready for python, excluding this stuff.

Nice!

Is anyone working on it?

I'll take a look right now.

[mbargull]

FYI, transitioning of tzdata to become a noarch: generic package with share/zoneinfo is almost done: conda-forge/tzdata-feedstock#1.