<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 2:02 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think the other linkage between the two is that pytz's "every tzinfo<br>
instance is fixed-offset" is the most natural way to solve the PEP-495<br>
problem in the absence of PEP 495 and ensure that all datetime instances<br>
are unambiguous and valid.</blockquote><div><br></div></span><div>Again (as can be seen from the endless bickering between Alexander and myself about whether this is a bug or not) your view is colored by pytz's position.</div></blockquote></div><br>I really regret that it came out as "bickering," because I am on Guido's side when it comes to a full DST aware tzinfo implementation.  The fixed offset tzinfo implementation came as a compromise between those who did not want any concrete tzinfo implementations in the stdlib and those who wanted a full-featured LocalZone implementation.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I still want to see  LocalZone in stdlib, but to me it is only a worthwhile addition if it follows the original Guido/Tim design.  If you want the aware instances that do timeline arithmetics - you already have two ways to do it: convert to UTC or convert to the "current" fixed offset timezone.</div></div>