Yeah, I'm aware of this, but I think the reality on the ground is that everyone everywhere deploys compiled zic files and will for the foreseeable future, it is the standard currency of time zone information, and we'll probably want to be able to at least fall back to this. I think we'd be better off lobbying for the addition of `SAVE` information into `zic` outputs than we would going out of our way to support other formats, but I think that at the very least we should be able to handle the compiled zic format so that it will be easy for people to access their system time zones. Currently the heuristic methods of determining DST offset are sufficient to cover all known cases - though obviously this is potentially fragile. Still, I think that users would *much* prefer a zoneinfo parser that is guaranteed to get the offset right 100% of the time and occasionally will incorrectly identify whether or not a zone is DST in the rare but possible event that a zone makes an STD->DST transition immediately followed by a DST->STD transition without any change in overall offset. Since the compiled zic format has a magic identifier at the beginning, it may be a fairly simple matter to have the parser support more than one type of zone information as inputs. One property that is also compiled from the IANA sources is the iCalendar format (this can be compiled with vzic https://github.com/libical/vzic for example). We could simply detect what kind of file it is and parse accordingly. That said, the implementation of a properly compliant iCalendar timezone parser is orders of magnitude more complicated than a simple zoneinfo parser. I don't love the idea of developing some homegrown Python format just to preserve the SAVE information. That will create a pretty significant indefinitely ongoing support burden compared to a zoneinfo parser that works with files already deployed by the OS. Best, Paul On 01/19/2018 02:16 PM, Alexander Belopolsky wrote:

On Fri, Jan 19, 2018 at 12:53 PM, Paul G <paul@ganssle.io> 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>.