On Mon, Jul 27, 2015 at 01:04:03AM -0500, Tim Peters wrote: > [Tim] > >> 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. > > [Lennart] > > We can't explicitly implement incorrect timezone aware arithmetic and > > then expect people to not use it. > > Python didn't implement timezone-aware arithmetic at all within a > single time zone. Read what I wrote just above. It implements naive > arithmetic within a single time zone. This usage of "time zone" is confusing. As far as I can tell, you really mean "UTC offset". A time zone would be something like "Europe/London", which has two different UTC offsets throughout the year (not to mention other historical weirdnesses), whereas arithmetic on a "timezone-aware" datetime is only going to work so long as you don't cross any of the boundaries where the UTC offset changes. I agree with you about pretty much everything else about datetime, just I find the terminology misleading. The only other thing I found really weird about datetime is how Python 2 had no implementation of a UTC tzinfo class, despite this being utterly trivial - but it's too late to do anything about that now, of course.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4