So I've been thinking over the idea of shipping the IANA zones as part of a Python "batteries included" type approach - which is something I've been negative about in the past because I think that it's really not a good idea to tie the zoneinfo data releases to any sort of binary or library release (in fact, I'm planning on moving dateutil's zoneinfo tarball into a separate package as of python-dateutil>=2.8.0, so that they can be updated out of cycle from one another).
That said, it's still somewhat glaring in its absence. Thinking about it, though, I think it's not at all unreasonable to include a zoneinfo *parser* into Python's `datetime` library, something similar to `dateutil.tz.tzfile`, where you can give it a zic-compiled binary and it will create a zoneinfo file from that. Additionally, `datetime` can do what `pytz` and `dateutil` *already* do, which is to use the system `zoneinfo` files *if they exist*. This would allow third party libraries shipping *only* the `tzdata` to supply the tzdata on platforms that down't ship with their own copies of the database.
Here's a rough sketch of the interface I'm thinking about (specific names don't matter, just the general concept):
1. datetime.TZPATH - tzdata search path (configurable at build time, defaults to `['/usr/share/zoneinfo']`) similar to `sys.path` 2. PYTHONTZPATH - environment variable similar to PYTHONPATH - this is prepended to the search path when importing `datetime` 3. datetime.tzfile(tzname, tzpath=None) - Searches the `tzpath` for `tzname`, if `tzpath` is not None, it should be list of locations to search for `tzname` in. 4. datetime.tzfile.from_stream(tzstream, name=None) - Create a tzfile from an arbitrary stream `tzstream`, with optional zone name `name` (this allows you to read something from a tarball for example)
For Windows and other platforms that do *not* ship with zoneinfo, third party libraries could provide the zoneinfo data either by manipulating `datetime.TZPATH` or by wrapping either `datetime.tzfile` or `datetime.tzfile.from_stream`.
I'd be happy to put together a PEP on this if people like the idea.
On Fri, Jan 19, 2018 at 12:53 PM, Paul G firstname.lastname@example.org wrote:
That said, it's still somewhat glaring in its absence. Thinking about it, though, I think it's not at all unreasonable to include a zoneinfo *parser* into Python's `datetime` library, something similar to `dateutil.tz.tzfile`
A variant of tzfile is in fact included, but buried in the datetime tester. Unfortunately, binary tz files distributed with many UNIX-like OSes do not preserve enough information to implement a high quality Python tzinfo subclass. The missing information is the breakdown of utcoffset into standard offset and dst. The tz files only store DST as a boolean and in the rare cases when DST differs from 1 hour, it is impossible to accurately figure out the .dst() timedelta.
If we go to the trouble of implementing a Zoneinfo parser, I suggest that we also include a parser for the raw IANA files that can extract the DST timedelta information from the "SAVE" field.
Note that I started toying with some related ideas at https://github.com/abalkin/tz.