[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 :-( _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
