<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 24, 2015 at 10:44 AM, Carl Meyer <span dir="ltr"><<a href="mailto:carl@oddbird.net" target="_blank">carl@oddbird.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/24/2015 11:18 AM, Guido van Rossum wrote:<br>
> I'm still unclear on why pytz solves two problems (timeline arithmetic<br>
> and a tzinfo database). What is the linkage between the two besides that<br>
> you (Stuart) feels that both are important problems to solve?<br>
<br>
</span>Didn't Stuart already answer this in his last email?<br>
<span class=""><br>
"Grump. I always interpreted that documentation to mean that timezone<br>
conversions where *my* problem as the author of the tzinfo<br>
implementation. I thought it was a documented problem to be fixed<br>
if/when Python ever provided more complex tzinfo implementations, and<br>
one of the reasons it never did provide such implementations in the<br>
first place."<br></span></blockquote><div><br></div><div>I guess he assumed wrong. We didn't consider the arithmetic we implemented broken at all. Our assumptions at the time were:<br><br></div><div>- If you want timeline arithmetic you will obviously be using UTC (either POSIX timestamps or datetime instances with assumed or explicit UTC)<br><br></div><div>- Implementing a tzinfo database is a huge project that we'd like to tackle at some point in the future (possibly as a 3rd party project)<br><br></div><div>I'm still confused about what makes Stuart believe a tzinfo database must also change the arithmetic rules (especially since Gustavo's dateutils apparently gets along quite well without this).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
"Classic behaviour as you describe it is a bug. It sounds ok when you<br>
state it as 'add one day to today and you get the same time tomorrow'.<br>
It does not sound ok when you state it as 'add one second to now and<br>
you will normally get now + 1 second, but sometimes you will get an<br>
instant further in the future, and sometimes you will get an instant<br>
in the past'."<br></span></blockquote><div><br></div><div>That sounds tautological to me -- "it's a bug because I find it buggy".<br><br></div><div>Maybe the underlying reason is that to me, even a datetime with tzinfo does not refer to an instant -- it refers to something that's displayed on a clock. To me, arithmetic is a way of moving the hands of the clock.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>In other words, he just assumed that timeline arithmetic was his only<br>
reasonable option as the author of a useful, non-buggy tzinfo<br>
implementation. As a user of pytz, it was certainly what I expected, and<br>
I'd have considered "classic arithmetic" to be a bug (thanks to pytz, I<br>
avoided even knowing that was Python's default behavior until this<br>
thread), so I can't fault his assumption.<br></blockquote><div><br></div><div>But again that proves nothing. Of course if you're used to pytz's behavior you'll find the other behavior buggy. And it still does nothing to explain (to me) why the two need to be inextricably linked.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Faced with "I need to store this extra<br>
disambiguation bit in the tzinfo somehow, to clarify which of two<br>
offsets is intended when a timezone transitions from one offset to<br>
another", you can either store a boolean somewhere which is usually<br>
irrelevant and very hard to name sensibly, or you can "store" the flag<br>
by simply assigning a tzinfo instance which represents the specific<br>
offset you want (but also knows its full timezone rules, so it can<br>
"normalize" to a different offset when asked to).<br></blockquote><div><br></div><div>But almost all instants (99.98%, according to Alexander) are not ambiguous and have no need for the disambiguation. If I every program an alarm to occur weekday at 7am I'd be most disturbed if an implementation botched the DST transition and woke me up at 6am one Monday morning. And yet that 7am is in a specific timezone (mine!).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once you choose the latter implementation (which you might reasonably<br>
choose even if you didn't care about arithmetic at all), Python gives<br>
you timeline arithmetic automatically.</blockquote><div><br></div><div>You've proved nothing except that pytz's view is seductive. :-)<br> <br></div></div>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>