This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Erik Cederstrand
Recipients Erik Cederstrand, martin.panter, p-ganssle
Date 2020-11-18.06:00:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605679230.22.0.443687378583.issue42094@roundup.psfhosted.org>
In-reply-to
Content
There are two conflicting interests: ISO 8601 that allows non-precise durations, and timedelta that assumes precise durations.

For me, the non-precise durations only make sense in date arithmetic - to a human, it's pretty clear what adding 3 months or a year will do to the date. There may be edge cases when crossing DST, but normal arithmetic with timezone also have those cases.

Regarding ISO weeks, I'm pretty sure that they are only special in regards to calculating week numbers and the weekday they start. They still have a duration of 7 days.

Apart from being able to parse ISO durations coming from other systems, the non-precise durations would be useful e.g. when implementing recurring events. Calculating a series of dates for something that happens on the 12th day of every 2nd month is doable in Python, but not with the aid of timedelta.

I see four options here:

1) expand timedelta to allow month and year, with the implication that e.g. total_seconds() would fail or be ambiguous for these timedeltas

2) implement only the parts of ISO 8601 that can safely be represented by the current timedelta

3) add a new relativetimedelta class that allows representing non-precise durations

4) do nothing and leave it to 3rd party packages to implement this
History
Date User Action Args
2020-11-18 06:00:30Erik Cederstrandsetrecipients: + Erik Cederstrand, martin.panter, p-ganssle
2020-11-18 06:00:30Erik Cederstrandsetmessageid: <1605679230.22.0.443687378583.issue42094@roundup.psfhosted.org>
2020-11-18 06:00:30Erik Cederstrandlinkissue42094 messages
2020-11-18 06:00:29Erik Cederstrandcreate