Re: [Datetime-SIG] Clearing up terminology
[Tim]
....I personally would have preferred that "aware" datetime objects use strict/timeline arithmetic instead, but it's not a big deal to me either way.
[[ijs]
I thought I understood what you were saying until now, but through this entire discussion I have been under the impression that you felt the exact opposite of that last sentence (except for the not being a big deal part).
Ah. but my "preferred" above is past tense. That's how I felt at the time - and would still feel if we were starting over from scratch. Throughout the vast bulk of _this_ entire discussion we've been talking about the present and foreseeable future (in which "starting over from scratch" doesn't exist). Now backward compatibility, and explaining how & why it's possible to live happily enough with the status quo,, are far more important than that one of Tim's mild preferences was frustrated a dozen years ago ;-)
[explains that strict/timeline arithmetic _is_ currently done when subtracting or comparing two aware datetimes]
[[ijs]
So once we have an is_dst bit, what will be the result of
tz = timezone('America/Chicago') datetime(2013, 11, 3, 1, 30, tzinfo=tz, is_dst=True) - datetime(2013, 11, 3, 1, 0, tzinfo=tz, is_dst=False)
?
I assume you already know, so I too will leave it as an exercise for the reader ;-)
How can it be consistent with current behavior and be anything other than timedelta(0, 1800), even though the first time preceded the second?
The result will change. The intended and documented behavior has always been to follow "strict arithmetic" rules in this case. So that it currently doesn't is, and always has been, a bug. Not a bug in subtraction itself, it's a bug in .utcoffset(), which couldn't possibly get all cases right before the is_dst flag was added. The instant utcoffset() is repaired, subtraction and comparison will be too. Of course it's possible that the change will break somebody's currently working code. But that's true of all bug fixes. I _might_ care if anyone could convince me that it has any real chance of breaking code except for some timezone wonk's collection of edge cases peppered with # EVIL PYTHON!!! HAVE THEY NO SHAME!!!!!??????!!!!!! comments ;-)
participants (1)
-
Tim Peters