Let's just agree to disagree. I don't want to argue any more. On Mon, Aug 24, 2015 at 11:30 AM, Carl Meyer <[email protected]> wrote:
> On 08/24/2015 12:02 PM, Guido van Rossum wrote: > > 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. > > Yes, I think that's the basis of the differing views here. > > Clocks don't show timezones, so if I just wanted to "move the hands of > the clock," I'd use a naive datetime, which is the proper representation > for "something that is displayed on the clock." > > A datetime with a tzinfo _does_ correspond to an instant (even if you > don't want to think of it that way), so to some of us it is confusing if > it occasionally behaves as if it does not. > > > In other words, he just assumed that timeline arithmetic was his only > > reasonable option as the author of a useful, non-buggy tzinfo > > implementation. As a user of pytz, it was certainly what I expected, > and > > I'd have considered "classic arithmetic" to be a bug (thanks to > pytz, I > > avoided even knowing that was Python's default behavior until this > > thread), so I can't fault his assumption. > > > > > > 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. > > It was the behavior I expected when I _first picked up_ pytz, and if I > hadn't gotten it from pytz, I'd have -- well, I'd have continued to do > store datetimes internally in UTC and do arithmetic in UTC, which is > what I do and recommend to others. But I'd have considered the > possibility of naive arithmetic with aware datetimes as an unnecessary > attractive nuisance and bug magnet. > > > I think the other linkage between the two is that pytz's "every > tzinfo > > instance is fixed-offset" is the most natural way to solve the > PEP-495 > > problem in the absence of PEP 495 and ensure that all datetime > instances > > are unambiguous and valid. > > > > > > 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. > > I think the argument about whether it's a bug has been unenlightening, > because it of course depends on what you want (and how you see > datetimes, as described above). I certainly think that pytz's need for > `normalize()` calls is most unfortunate (and I know Stuart agrees with > that). But it preserves the most important thing (from my perspective), > which is that the resulting datetime always corresponds to the right > instant, even if it's got the offset wrong until you normalize it. Given > the limited options Stuart had, I think that was the best choice > available for my use cases (and apparently his). > > > Faced with "I need to store this extra > > disambiguation bit in the tzinfo somehow, to clarify which of two > > offsets is intended when a timezone transitions from one offset to > > another", you can either store a boolean somewhere which is usually > > irrelevant and very hard to name sensibly, or you can "store" the > flag > > by simply assigning a tzinfo instance which represents the specific > > offset you want (but also knows its full timezone rules, so it can > > "normalize" to a different offset when asked to). > > > > > > But almost all instants (99.98%, according to Alexander) are not > > ambiguous and have no need for the disambiguation. > > Of course. But that can easily be an argument in favor of pytz's > implementation choice. Why give every tzinfo a boolean flag that is > worse-than-useless (because its presence and naming is confusing) in the > 99.98% of cases when it's not needed, when you can instead give every > tzinfo an unambiguous offset and eliminate the problem? > > 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!). > > This example is meaningless, because "program an alarm to occur every > weekday at 7am" is not a valid use case for any type of datetime > duration arithmetic at all. It's a use case for a period recurrence, > which is an entirely different beast (e.g. dateutil.rrule). It's the > same type of operation as "notify me every second Saturday," not as > "what will the time be in 15 seconds". > > Programming that use case using "add 86400 seconds to the time my alarm > went off yesterday" is certainly a possible newbie mistake someone might > make who hasn't worked with timezones or DST before (and who also forgot > the "weekdays only" requirement), but it's a mistake that should be > fixed by pointing them to a recurrence library, not by having aware > datetimes use naive arithmetic. > > Carl > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
