[Akira Li <4kir4.1i@gmail.com>] ...
I agree on the best practices here. I would prefer that __add__ would be forbidden for local timezones unless they have a fixed utc offset. But it might be too late for that now.
It's many years too late to change anything about datetime arithmetic in any backward-incompatible way.
If __add__ is allowed for timezone-aware datetime objects
It already is.
then arithmetic "as though via conversion to utc time" is *equally valid* as the arithmetic "as though it is a timezone-naive datetime object".aa
__add__ can only mean one of them. And it already does. It _could_ have meant the other, but it doesn't. ...
Apps that care about leap seconds _should_ be using TAI. Apps that want timeline arithmetic _should_ be using UTC. Unfortunately, people shoot themselves in the feet all the time. Python can't stop that. But it doesn't have to _cater_ to poor practices either.
By your logic: Apps that care about timezone-naive arithmetic _should_ be using naive datetime objects.
As I've said several times before, that's indeed what I would have _preferred_. But it was only a mild preference. Since timeline arithmetic is far better done in UTC anyway, I'm "happy enough" with aware datetimes using classic arithmetic. Indeed, my own code uses that frequently, and so does datetime's implementation. Several examples of that have been given in other messages.
I agree it is a poor practice to perform arithmetic on localized time. But as long as such arithmetic *is* allowed then it *is* ambiguous what type of arithmetic should be used. There is no *one obvious* way here.
Sure. But this isn't a case of "in the face of ambiguity refuse the temptation to guess". It's a case of "in the face of ambiguity, pick one, document the choice, and move on". Similarly, when printing a floating point number, there are _many_ equally valid choices for how many digits to display after the decimal point. That's no argument for refusing to print floats. Python has made different choices about that over time. If you don't like Python's default choice, with enough extra work you can force any number of digits you like. And if you don't like classic arithmetic, with enough extra work you can get any other kind of datetime arithmetic you like.
... dateutil doesn't work during DST transitions but PEP 495 might allow to fix it. ... I've linked to a couple of dateutil bugs previously in PEP-431/495 thread [1]
I was surprised as you that dateutil .fromutc() appears to be broken.
I use "might" because I haven't read dateutil code. I can't be sure e.g., what backward-compatibility concerns might prevent PEP 495 fix its issues with an ambigous local time.
Sorry, I haven't been (and won't be) making time to stare at bugs in other packages. I probably know less about them than you do anyway. Python has always had tests for proper DST transition UTC->local conversions for the kind of tzinfo classes the docs suggest writing. But do note that "proper" in this context _only_ means "mimics the local clock" (gets the repeated or missing YYYY-MM-DD HH:MM:SS behaviors right). Without a disambiguation flag, it's flatly impossible to always get the zone name and/or UTC offset right for ambiguous local-clock hours.
Timezones is a very complicated topic -- no solution works in the general case.a
? Timezone transitions are mathematically trivial. They're just full of lumps (irregularities).
... The only my objection that timezone-naive arithmetic is somehow superior for localized times.
It's not only superior, it's essential for some purposes. For other purposes, it''s worse than useless.
Though I don't mind it as long as timezone conversions would work.
Good! That's precisely what PEP 495 intends to make possible.
...
If dateutil can be fixed to work correctly using the disambiguation flag then its behavior is preferable because it eliminates localize, normalize calls
... The key word here is "If". *If* it works; great.
I can't speak for dateutil or its author. But we're not doing brain surgery here. Conversion just isn't a deep problem. The only non-trivial cases involve ambiguous times. C fixed that long before Python existed with is_dst, although granted that mktime() is notoriously flaky across platforms in edge cases.
It is still possible to perform both types of arithmetic as the examples above demonstrate.
That's always been possible - except for errors in timeline arithmetic inherited from the rare failing conversion cases. 495 allows to repair all failures.
... [more about pytz and dateutil] .;..
Please don't take offense at my chopping this. It's only that I need to make _some_ time tonight for 495 ;-)