Re: [Datetime-SIG] What's are the issues?
In the interest of continuing to lay the foundation for discussion, let me build on Chris's recap before giving my viewpoint on the issue: 1. Datetime arithmetic
a) datetime +/- timedelta ii. Aware (with tzinfo) datetime objects
If the math is done in UTC, then there is no issue, yes? the timedelta is added or subtracted, and the result has the same tzinfo object.
If I've understood correctly, this is one of the bigger points of contention. Specifically, the following operation is quite polarizing: `datetime(2015, 3, 7, 13, 0, tzinfo=zoneinfo('America/New_York') ) + timedelta(days=1)` It raises the following two questions: * Should `days=1` be interpreted the same as `hours=24`? * If it is interpreted the same, should the addition be "naive" (not adjusting for the jump from 1:59 to 3:00) or "aware" Current semantics call for the answers to be "yes" and "naive"
b) datetime - datetime
ii. When both have same tzinfo
Just do the math. Store as UTC makes it easy. return a timedelta.
This is another contentious issue. What do you want `datetime(2015, 3, 8, 13, tzinfo=zoneinfo('America/New_York')) - datetime(2015, 3, 7, 13, tzinfo=zoneinfo('America/New_York'))` to be? There's a camp for `timedelta(seconds=24 * 60 * 60)` and a camp for `timedelta(seconds=23 * 60 * 60)`, though I think everyone agrees that `(dt + delta) - dt == delta` is necessary. 2. Inter-timezone conversion
b) algorithm specification
what part of the algorithm? seems pretty straightforward to me (the algorithm, anyway)
I'm less clear on the issue here, but Isaac seemed to disagree with the algorithm in datetime.py ( https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1935) [ http://code.activestate.com/lists/python-dev/137300/]
participants (1)
-
Felipe Ochoa