PEP 615: Add zoneinfo module

[pganssle]

BPO	40503
Nosy	@malemburg, @Yhg1s, @abalkin, @serhiy-storchaka, @zooba, @pganssle, @isuruf, @FFY00
PRs	bpo-40503: Add tests and implementation for ZoneInfo #19909 bpo-40503: Add documentation and what's new entry for zoneinfo #20006 bpo-40503: Add compile-time configuration to PEP 615 #20034 gh-84683: Check in <prefix>/share/zoneinfo for zoneinfo files on Windows #28495

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/pganssle'
closed_at = None
created_at = <Date 2020-05-04.18:51:21.137>
labels = ['type-feature', 'library', '3.9']
title = 'PEP 615: Add zoneinfo module'
updated_at = <Date 2021-09-21.20:27:37.648>
user = 'https://github.com/pganssle'

bugs.python.org fields:

activity = <Date 2021-09-21.20:27:37.648>
actor = 'steve.dower'
assignee = 'p-ganssle'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-05-04.18:51:21.137>
creator = 'p-ganssle'
dependencies = []
files = []
hgrepos = []
issue_num = 40503
keywords = ['patch']
message_count = 17.0
messages = ['368076', '368461', '368619', '368634', '368649', '368656', '368658', '368800', '369021', '369059', '369206', '401992', '402247', '402330', '402350', '402352', '402357']
nosy_count = 8.0
nosy_names = ['lemburg', 'twouters', 'belopolsky', 'serhiy.storchaka', 'steve.dower', 'p-ganssle', 'isuruf', 'FFY00']
pr_nums = ['19909', '20006', '20034', '28495']
priority = 'high'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue40503'
versions = ['Python 3.9']

[pganssle]

This is an issue to track the implementation of PEP-615: https://www.python.org/dev/peps/pep-0615/

It should mostly involve migrating from the reference implementation: https://github.com/pganssle/zoneinfo/

[pganssle]

I've separated this into two separate PRs, one for docs and one for tests/implementation.

I have not yet implemented the logic for the ability to configure the TZPATH at compile time because I'm not quite sure how to start on that. How are other compile-time options implemented? Do I need to do something special to handle both Windows and POSIX systems? Is there already a configuration file somewhere that I should use for this? Adding Thomas to the nosy list because he's the only one listed for "autoconf/makefiles" – don't know if that extends to the Windows build as well.

[Yhg1s]

The normal way to do this (for make/autoconf) is to add a --with-tzpath argument to configure.ac, and a make variable to pass it to the compilation of anything that needs it. You can then access it from Python code with sysconfig.get_config_var().

In configure.ac, AC_SUBST(TZPATH) makes configure replace @TZPATH@ in the Makefile with the value you set to $TZPATH in configure.ac. You then either add that to the global PY_CFLAGS_NODIST, or modify the build rule for the module that needs it to pass it along. (See for example how GITTAG/GITVERSION/GITBRANCH are passed to Modules/getbuildinfo.o.)

AC_ARG_WITH() is how you add a new --with-* argument to configure. The usual way people do this is by copying one of the other AC_ARG_WITH blocks and modifying it to suit their needs. It's a mixture of m4 and shell that can be a bit annoying to get right, but it's pretty flexible. Run autoreconf to regenerate configure. You can manually check that the shell in configure makes sense.

Something will have to be done on the Windows side as well, but I'm not sure what. Adding Steve Dower for that.

[pganssle]

Thanks Thomas, that was super helpful. I've created #64233 to add in the compile-time arguments on POSIX systems at least, do you mind having a look?

For the moment I have made it non-configurable on Windows, but I think the right thing to do is to add an argument to PCbuild\build.bat. Hopefully Steve can point me in the right direction for mapping that argument (or something else) to a new config variable in sysconfig.

[serhiy-storchaka]

Do we need the C implementation if there is the Python implementation?

[pganssle]

I mean, theoretically we don't "need" it, but it's much, much faster, and without it nearly every operation that needs time zone offsets will be slower than pytz (which has a mechanism for caching).

Also, I've already written it, so I see no reason why not use it.

[pganssle]

Here are some benchmarks run using the latest implementation. The pure Python code is pretty optimized, but the C code is still ~4-5x faster.

Running from_utc in zone Europe/Paris
c_zoneinfo: mean: 494.82 ns ± 3.80 ns; min: 489.23 ns (k=5, N=500000)
py_zoneinfo: mean: 2.48 µs ± 79.17 ns; min: 2.42 µs (k=5, N=100000)
dateutil: mean: 10.41 µs ± 209.97 ns; min: 10.17 µs (k=5, N=50000)
pytz: mean: 4.69 µs ± 252.70 ns; min: 4.39 µs (k=5, N=50000)

Running to_utc in zone Europe/Paris
c_zoneinfo: mean: 539.61 ns ± 25.68 ns; min: 514.39 ns (k=5, N=500000)
py_zoneinfo: mean: 2.01 µs ± 61.69 ns; min: 1.94 µs (k=5, N=100000)
dateutil: mean: 7.88 µs ± 506.89 ns; min: 7.25 µs (k=5, N=50000)
pytz: mean: 773.02 ns ± 14.11 ns; min: 759.56 ns (k=5, N=500000)

Running utcoffset in zone Europe/Paris
c_zoneinfo: mean: 329.34 ns ± 36.31 ns; min: 302.88 ns (k=5, N=1000000)
py_zoneinfo: mean: 1.57 µs ± 9.58 ns; min: 1.55 µs (k=5, N=200000)
dateutil: mean: 6.28 µs ± 86.61 ns; min: 6.16 µs (k=5, N=50000)
pytz: mean: 461.47 ns ± 2.07 ns; min: 458.91 ns (k=5, N=500000)

utcoffset() is very likely to be called possibly many times in certain hot loops (including implicitly as it's part of hash and equality checks).