[Lennart Regebro <regebro at gmail.com>]
> Of course, I meant datetime objects.
> In everything else, I stand by my original claim. If you want naive
> datetime obejcts, you should use naive datetime objects.
That's tautological ("if you want X, you should use X"). I'm not sure
what you intended to say. But it's a fact that some apps do need
DST-aware datetime objects, and also need naive datetime arithmetic on
those objects. The point isn't that there's no way to get the latter
if Python datetime arithmetic changed; the point is that it _already
works_ for them, and has for 12 years. You can't break apps without
overwhelmingly compelling reason(s). Please move on to think about
backward-compatible ways to get what you want instead.
In the meantime, writing little functions to do the
convert/arithmetic/convert dance is "the obvious" way to get what you
want.
> My opinion is and remains that intentionally breaking datetime
> arithmetic to make non-naive objects behave in a naive way was a
> mistake.
While other people think it was a fine and useful compromise. It's
certainly fortunate that repetition changes minds ;-) Regardless,
that decision is ancient history now.
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