[Lennart Regebro <rege...@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.
_______________________________________________
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
