On Fri, Aug 28, 2015 at 5:26 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

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

Again, that sounds like perfection being the enemy of the good. :-( Those issues are resolved by the demo class however mktime() resolves them when tm_isdst is set to -1. Outside the fold it should work fine, and in the fold it should work as well as can be expected. :-) 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.

OK, that's definitely a concern.

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.

(But can a TZ database ever be considered complete? :-) I think the best way out of this will be for there to be two different local timezone objects: one that always defers to what the time module reveals about local time, another that is always tied to the local zone as it is recorded in the tz database. The two may differ even if they agree about the tz name; the tz database may have historical details that are missing from the implementation consulted by mktime() and localtime() (e.g. on Windows, or using certain encodings of the TZ environment variable on certain systems). -- --Guido van Rossum (python.org/~guido)