On Fri, Aug 28, 2015 at 8:06 PM, Guido van Rossum <[email protected]> wrote:
> .. > So, again, why have we been shy of adding this to the stdlib? We did > (eventually) add the fixed offset classes. > I may be wrong, but I thought it was due to unresolvable DST fold issues that are mooted by PEP 495. (At least that was the reason I did not push for LocalTimezone as hard as I did for the fixed offset class.) I am definitely +1 on having LocalTimezone (or timezone.local) in the datetime module, but there is one reason why I would rather see it as a part of a larger Olson TZ database-size offering. If we just add LocalTimezone, pickling a datetime instance on one system and reading it on another with a different TZ will result in changing the time value. On the other hand, if we have a complete TZ database, then LocalTimezone can simply become an alias for Zoneinfo(os.environ['TZ']) and there will be no problem sharing aware datetime objects between systems that use the same version of the database.
_______________________________________________ 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/
