On 26 July 2015 at 18:12, Lennart Regebro <rege...@gmail.com> wrote: > On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters <tim.pet...@gmail.com> wrote: >> The Python docs also are quite clear about that all arithmetic within >> a single timezone is "naive". That was intentional. The _intended_ >> way to do "aware" arithmetic was always to convert to UTC, do the >> arithmetic, then convert back. > > We can't explicitly implement incorrect timezone aware arithmetic and > then expect people to not use it. We can make the arithmetic correct, > and we can raise an error when doing tz-aware arithmetic in a > non-fixed timezone. But having an implementation we know is incorrect > and telling people "don't do that" doesn't seem like a good solution > here. > > Why do we even have timezone aware datetimes if we don't intend them > for usage? There could just be naive datetimes, and timezones, and let > strftime take a timezone that is used when formatting. And we could > make date-time creation into a function that parses data including a > timezone, and returns the UTC time of that data. > > But then again, if we do that, we could just as well have that > timezone as an attribute on the datetime object, and let strftime use > so it doesn't have to be passed in. And we could let the __init__ of > the datetime take a timezone and do that initial conversion to UTC.
I think we need to make sure to separate out the question of the semantic model presented to users from the internal implementation model here. As a user, if the apparent semantics of time zone aware date time arithmetic are accurately represented by "convert time to UTC -> perform arithmetic -> convert back to stated timezone", then I *don't care* how that is implemented internally. This is the aspect Tim is pointing out is a change from the original design of the time zone aware arithmetic in the datetime module. I personally think its a change worth making that reflects additional decades of experience with time zone aware datetime arithmetic, but the PEP should be clear that it *is* a change. As Alexander points out, the one bit of information which needs to be provided by me as a *user* of such an API (rather than its implementor), is how to handle ambiguities in the initial conversion to UTC (whether to interpret any ambiguous time reference I supply as a pre-rollback or post-rollback time). Similarly, the API needs to tell *me* whether a returned time in a period of ambiguity is pre-rollback or post-rollback. At the moment the "pre-rollback" flag is specifically called "is_dst", since rolling clocks back at the end of DST period is the most common instance of ambiguous times. That then causes confusion since "DST" in common usage refers to the entire period from the original roll forward to the eventual roll back, but the extra bit is only relevant to time zone arithmetic during the final two overlapping hours when the clocks are rolled back each year (and is in fact relevant any time a clock rollback occurs, even if the reason for the rollback has nothing to do with DST). The above paragraphs represent the full extent of my *personal* interest in the matter of the datetime module changing the way it handles timezones - I think there's a right answer from a usability perspective, and I think it involves treating UTC as the universal time zone used for all datetime arithmetic, and finding a less confusing name for the "isdst" flag (such as "prerollback", or inverting the sense of it to "postrollback", such that 0/False referred to the first time encountered, and 1/True referred to the second time encountered). There's a *separate* discussion, which relates to how best to *implement* those semantics, given the datetime module implementation we already have. For the original decimal module, we went with the approach of storing the data in a display friendly format, and then converting it explicitly as needed to and from a working representation for arithmetic purposes. While it seems plausible to me that such an approach may also work well for datetime arithmetic that presents the appearance of all datetime arithmetic taking place in terms of UTC, that's a guess based on general principles, not something based on a detailed knowledge of datetime in particular (and, in particular, with no knowledge of the performance consequences, or if we have any good datetime focused benchmarks akin to the telco benchmark that guided the original decimal module implementation). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
