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

[Loris Bennett]

Jon Ribbens <jon+usenet at unequivocal.eu> writes:

> 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).

Yes, I do mean just the trivial definitions from 

  https://docs.python.org/3/library/datetime.html

i.e.

    A millisecond is converted to 1000 microseconds.
    A minute is converted to 60 seconds.
    An hour is converted to 3600 seconds.
    A week is converted to 7 days.

plus a 24-hour day and a 365-day year.  

> 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.

If I am merely trying to represent part a very large number of seconds
as a number of years, 365 days per year does not seem that controversial
to me.  Obviously there are issues if you expect all periods of an
integer number of years which start on a given date to all end on the
same date.

In my little niche, I just need a very simple period and am anyway not
bothered about years, since in my case the number of days is usually
capped at 14 and only in extremely exceptional circumstances could it
get up to anywhere near 100.

However, surely there are plenty of people measuring durations of a few
hours or less who don't want to have to deal with seconds all the time
(I am in fact also in this other group when I record my working hours).

Cheers,

Loris

-- 
This signature is currently under construction.