Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

Jon Ribbens jon+usenet at unequivocal.eu
Tue Apr 19 09:15:15 EDT 2022


On 2022-04-19, Loris Bennett <loris.bennett at fu-berlin.de> wrote:
> Jon Ribbens <jon+usenet at unequivocal.eu> writes:
>> On 2022-04-19, Loris Bennett <loris.bennett at fu-berlin.de> wrote:
>>> I now realise that timedelta is not really what I need.  I am interested
>>> solely in pure periods, i.e. numbers of seconds,
>>
>> That's exactly what timedelta is.
>>
>>> that I can convert back and forth from a format such as
>>>
>>>   11-22::44:55
>>
>> I don't recognise that format and can't work out what it means.
>> It should be trivial to write functions to parse whatever format
>> you wanted and convert between it and timedelta objects though.
>
> days-hours:minutes:seconds

If by 'days' it means '86,400 seconds' then that's very easily
convertible to and from timedelta.

>> I would be very surprised if any language supported the arbitrary format
>> above you happen to be interested in!
>
> But most languages support fairly arbitrary formatting of timedate-style
> objects.  It doesn't seem unreasonable to me that such formatting might
> be available for simple periods.
>
>>> I would have thought that periods crop up all over
>>> the place and therefore formatting as strings and parsing of string
>>> would be supported natively by most modern languages.  Apparently not.
>>
>> I think most languages think that a simple number suffices to represent
>> a fixed time period (commonly seconds or milliseconds). And if you want
>> more dynamic intervals (e.g. x months y days) then there is insufficient
>> consensus as to what that actually means.
>
> Maybe.  It just seems to me that once you get up to more than a few
> hundred seconds, the ability to convert and from a more readable format
> becomes very useful.  The length of a month may be unclear, but the
> definitions for year, week, day, hours, and minute are all trivial.

Eh? The definitions for "year, week, day" are not in the slightest bit
trivial (unless you define 'day' as '86,400 seconds', in which case
'year' is still not remotely trivial).

I think the issue is simply lack of consensus. Even though ISO 8601,
which is extremely common (possibly even ubiquitous, for anything
modern) for the format of date/times, also defines a format for
durations (e.g. 'P4Y3M' for '4 years 3 months'), I don't think
I have ever seen it used in practice - not least because apparently
it doesn't define what it actually means. So there isn't one simple
standard agreed by everyone that is an obvious candidate for inclusion
in language standard libraries.


More information about the Python-list mailing list