<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 22, 2015 at 4:43 PM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 22, 2015 at 7:02 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:</div><div class="gmail_quote">[Alexander Belopolsky]<span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The feature lack of which you may find disappointing is that we don't have the means in the stdlib to get the following:</div><div> </div><div><span style="font-size:12.8000001907349px">>>> t = datetime.now(LocalZone)</span><br></div><div><span style="font-size:12.8000001907349px">>>> t</span><span style="font-size:12.8000001907349px">.</span><span style="font-size:12.8000001907349px">strftime('%F %T %Z%z')</span></div><div><span style="font-size:12.8000001907349px">'2015-08-22 17:45:51 EDT-0400'</span><span style="font-size:12.8000001907349px"><br></span></div><div><span><div class="gmail_extra" style="font-size:12.8000001907349px">>>> (t + timedelta(100)).strftime('%F %T %Z%z')</div></span><span><div class="gmail_extra" style="font-size:12.8000001907349px">'<span><span>2015-11-30 16:45:51 EST-0500</span></span>'</div></span></div><div class="gmail_extra" style="font-size:12.8000001907349px"><br></div><div class="gmail_extra" style="font-size:12.8000001907349px">I agree.  It would be nice to have something like this (and agree whether it should return <span style="font-size:small"><span><span>17:45</span></span> or </span><span style="font-size:small"><span><span>16:45</span></span></span><span style="font-size:12.8000001907349px">).  However, this has nothing to do with having or not having the bug in the library that we ship today.</span></div><div class="gmail_extra" style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"><br></span></div><div class="gmail_extra" style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">At some point we draw the line saying that the standard datetime module will only implement fixed offset timezones.  These timezones were implemented and for the most part correctly.  At least in the examples that I provided the code works the way I expect it to work.</span></div></div></div></div></blockquote></div></div></div></div></blockquote></span><div>[Guido van Rossum]</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><br></div></div></div><div class="gmail_extra">Ah. I think I finally understand why we're failing to communicate. Your claim is merely that the stdlib doesn't have the means to construct a tzinfo with the desirable behavior from the timezone information available in the time module. We have the tzname tuple and the offset for the current time, but nothing about the DST transition algorithm, so the best we can do is create a fixed-offset tzinfo for the current offset. I will give you that.<br></div></blockquote><div><br></div></span><div>It's not that we don't have the means.  After all, the mktime-based <span style="font-size:12.8000001907349px">LocalZone implementation have been presented in the library manual for ages.  I think it was the same ambiguity about folds and gaps and the traditional vs. timeline arithmetic that prevented it from getting into the datetime module.</span></div><div> </div><div>The fixed offset timezones solved a very practical problem: you get an email for someone in Australia with a timestamp in UTC+10:00 timezone (which includes +1000 in it) and you want to compare it to datetime.now().  This problem is solved in Python 3.3+.  As a bonus, you also have means of doing the timeline arithmetic, but not as easily as one might wish.</div></div></div></div></blockquote><div><br></div><div>I would have solved this problem (and any other problem that requires timeline arithmetic) by converting to a timestamp and comparing to time.time().<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br></div><div class="gmail_extra">What I am objecting to is that when you ask pytz to construct a datetime from a DST-aware timezone, it produces a datetime whose tzinfo has a fixed offset. Such a datetime then exhibits the same behavior as shown in your example for LocalZone, even though pytz has the DST rules for the original timezone -- and this is what I called "trading one bug for another" (since pytz does this in order to obtain timeline arithmetic).<br></div></blockquote><div><br></div></span><div>The author of pytz had no means of storing the extra bit necessary to do timeline arithmetic in local time notation in the datetime object.  So for him, what was a more or less an arbitrary choice for us was a necessity.  As Tim characterized it, Stuart made a heroic effort to overcome that limitation. Hopefully with PEP 495 we will resolve this issue once and for all.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">But PEP 495 doesn't add timeline arithmetic (it merely makes it easier to convert between timestamps and datetimes and back, except for the rounding issue).<br><br></div><div class="gmail_extra">I wonder why Stuart needed timeline arithmetic? Merely being able to access the Olson database doesn't sound enough of a reason for such heroism.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>