Currently timedelta values can be specified in two ways:
using local times: retry-after = 00:02:30
using suffixes: delete-after-days = 30
The suffixes are useful for specifying durations longer than one day. However, there is a problem: a suffix is applied to the key, so it requires a key to be present. In arrays, elements have no key, so we currently can't specify durations of more than a day inside an array.
The suffix mechanism also complicates the implementation, so that's a reason to drop the suffix mechanism instead of only supplementing it by another mechanism.
The alternative would be to put the information in the value instead of the key, for example:
A problem with using ISO 8601 is that it doesn't map properly to timedelta, as noted in this Python issue: every unit above hour is considered a nominal duration rather than an exact duration. In the case of years and months the nominal interpretation is the only one possible, in the case of weeks and days it's a choice that makes sense in some use cases, but timedelta doesn't support it.
Go defines a number + unit format that seems usable, but its largest unit is hours, so we'd have to extend the format to support days as well.
one that is similar to ISO 8601, but drops support for years and months and treats days as fixed 24 hours
one that is similar to Go's format, but adding days and supporting whitespace
The inline table format is very readable, but a bit verbose. As values have to be written by the user, verbosity is relevant. I have also not seen a format like this used elsewhere, so it scores low on user familiarity.
I'm leaning towards the HTML number + unit format, because it's simple, familiar and doesn't suggest compatibility with ISO 8601 that timedelta cannot provide. It also leaves open the possibility to bind ISO 8601 durations to a data type like dateutil.relativedelta in the future while providing some clarity and type safety by using a different format for each duration type.
Currently
timedeltavalues can be specified in two ways:retry-after = 00:02:30delete-after-days = 30The suffixes are useful for specifying durations longer than one day. However, there is a problem: a suffix is applied to the key, so it requires a key to be present. In arrays, elements have no key, so we currently can't specify durations of more than a day inside an array.
The suffix mechanism also complicates the implementation, so that's a reason to drop the suffix mechanism instead of only supplementing it by another mechanism.
The alternative would be to put the information in the value instead of the key, for example:
P30D30d{days = 30}A problem with using ISO 8601 is that it doesn't map properly to
timedelta, as noted in this Python issue: every unit above hour is considered a nominal duration rather than an exact duration. In the case of years and months the nominal interpretation is the only one possible, in the case of weeks and days it's a choice that makes sense in some use cases, buttimedeltadoesn't support it.Go defines a number + unit format that seems usable, but its largest unit is hours, so we'd have to extend the format to support days as well.
The HTML spec defines two duration formats:
The inline table format is very readable, but a bit verbose. As values have to be written by the user, verbosity is relevant. I have also not seen a format like this used elsewhere, so it scores low on user familiarity.
I'm leaning towards the HTML number + unit format, because it's simple, familiar and doesn't suggest compatibility with ISO 8601 that
timedeltacannot provide. It also leaves open the possibility to bind ISO 8601 durations to a data type likedateutil.relativedeltain the future while providing some clarity and type safety by using a different format for each duration type.