Add to/from string methods to datetime.timedelta

[tebeka]

BPO	41254
Nosy	@tebeka, @abalkin, @ericvsmith, @vadmium, @pganssle

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-07-09.06:46:58.269>
labels = ['type-feature', 'library', '3.10']
title = 'Add to/from string methods to datetime.timedelta'
updated_at = <Date 2021-07-30.16:00:44.744>
user = 'https://github.com/tebeka'

bugs.python.org fields:

activity = <Date 2021-07-30.16:00:44.744>
actor = 'matthewkenigsberg'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-07-09.06:46:58.269>
creator = 'tebeka'
dependencies = []
files = []
hgrepos = []
issue_num = 41254
keywords = []
message_count = 5.0
messages = ['373380', '373400', '373439', '374017', '398564']
nosy_count = 6.0
nosy_names = ['tebeka', 'belopolsky', 'eric.smith', 'martin.panter', 'p-ganssle', 'matthewkenigsberg']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue41254'
versions = ['Python 3.10']

[tebeka]

I suggest adding datetime.timedelta methods that convert to/from str.

The reason is that I have several places where configuration contains various timeouts. I'd like to write '50ms' and not 0.05 which is more human readable.

See https://golang.org/pkg/time/#ParseDuration for how Go does it.

[vadmium]

I don't know how much support this will get since there is already a str(timedelta) operation defined with a different format. But I don't like that format much. The day[s] part is too verbose, the H:MM:SS part could too easily be interpreted as D:HH:MM, and the result for negative deltas is horrible (-43 days, 23:59:55; see bpo-38701).

My favourite format for a duration is usually the HTML 5 format like

1w 0d 12h 0m 27s

Another option is ISO 8601 format:

P1W0DT12H0M27S

But both of these standards only go down to the seconds unit, so 50 ms has to be 0.05s or PT0.05S.

[tebeka]

I think the lack sub second parts in these formats is a disadvantage.
There's a merit in using a standard but IMO it's more natural to write someting like "2s" in a configuration value than "P2S" which is more cryptic.

[pganssle]

I think it is unlikely that we'll want to experiment with this directly in CPython. I don't think a fixed format (other than the annoying one that you already get from calling str on a timedelta) is appropriate, but designing a modular format for time differences is more complicated than it might seem. I have had an open issue on dateutil to implement this for ages, but I haven't seen or come up with any proposals for a DSL for specifying timedelta formats: dateutil/dateutil#444

It is annoyingly complicated to do this, and I'd rather it be tried out in other libraries with more flexibility to make breaking changes and a shorter release cadence. Dateutil is a good choice, but a clear and thorough proposal (or at least examples of this done well in other ecosystems we can crib from) is necessary.

[matthewkenigsberg]

I think it would be nice to have a from str method that could reverse the behavior of str(timedelta). I'm trying to parse files that contain the output of str(timedelta), and there's no easy way to get them back to timedelta's