[Datetime-SIG] IANA TZ database statistics

[Tim Peters]

[Alex]
> ...
> This is not about new tzinfos.  This is about implementing PEP 495's
> .astimezone().

Ah.  You realize that's the first time that's been mentioned in this
thread?  It's been a total mystery until now ;-)


> ...
> This is not about wrapping IANA's tzdist.  This is about implementing PEP
> 495 features using POSIX APIs.

Specifically which features?  Do you just mean .astimezone() treating
a naive datetime as being in the system zone, and the absence of any
argument implying the system zone?  Or more than just that?


>> ...
>> In that case, "best" is returning what the IANA database
>> says should be returned in all cases.

> Which version of  IANA database?

If it's still relevant, the only version any user cares about:  the
one that happens to be installed on their machine ;-)


> ...
> I don't want to try to figure out how to access tzfiles in a portable way.
> We need another PEP for this because I don't see any better solution than to
> repackage IANA files as a pip-installable package.  Such PEP should probably
> be discussed on distutils-sig first.

Sorry, since this thread started by presenting statistics about the
contents of the IANA database, I three-quarters assumed that _was_
what this was about.  I agree that needs a whole different PEP.

I also agree figuring out the system zone's rules is a puzzle using
POSIX.  Note that Gustavo gave up on trying to use mktime() in
dateutil's tzlocal class.  You could say time.timezone and
time.altzone define the only two (or one, if time.daylight is 0)
possible total UTC offsets, and assume that's always been, and always
will be, the case.  But I don't think even `altzone` is actually
required by POSIX - it's of little help :-(