On Fri, Aug 28, 2015 at 8:06 PM, Guido van Rossum
.. 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.