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

[Chris Angelico]

On Wed, 20 Apr 2022 at 02:16, 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 I can convert back
> and forth from a format such as
>
>   11-22::44:55
>
> (These are the lengths of time a job has run on an HPC system - leap
> seconds and time zones are of no relevance).

Thing is, there's a huge difference between:

1) "Eleven days, twenty-two hours, forty-four minutes, and fifty-five seconds"
2) "The period between 2nd May 2009 at 6AM and 5th June 2010 at 9AM"
3) "The period between 20th Feb 2016 at 10PM in New York and 30th Mar
2016 at 1AM in New York"
3b) "The period between 23rd Jan 1918 and 15th Feb 1918 in Moscow"

The first one is an abstract distance of time, and could be considered
broadly equivalent to the difference between two TIA timestamps or two
Unix times. Or UTC, as long as you don't care about inaccuracy around
leap seconds.

The second is a specific time period without a time zone. If assumed
to be UTC, or on an abstract calendar, it can be converted to and from
the first form, but if it's assumed to be local time, then it's
underspecified. It's affected by leap years, so you have to specify
the full date.

The third, and possibly fourth, are affected by civil time. (3b is
also potentially affected by a calendar switch; for people in Russia
at the time, the 23rd of January was a Julian date and the 15th of
February was a Gregorian date, so they were closer together than on
either calendar consistently. But I'd be fine with ignoring that, and
requiring the use of the Gregorian (or ISO, which is derived from it)
calendar.) Civil time is modified by regular adjustments (mostly DST),
official changes to time zone (eg the introduction or abolition of
DST, or choosing to align one's timezone with a neighbour), adoption
of standard time (often adjusting by a few minutes and/or seconds to
align with an hour boundary), etc, etc, etc. The only way to handle
civil time is (a) with full timestamps including the year, and (b)
with a complete timezone database listing all conversions. At this
point, the time period no longer has any abstract meaning, and its
sole meaning is "the time between these instants"; as such, it's
probably best calculated by converting the timestamps to UTC,
converting to Unix time, and taking the difference in seconds.

With the first option, there's no real meaning to it until you figure
out what you can actually *do* with that time period.

I believe ISO 8601 timestamps are about the most general you'll ever
need, with the possible exception of "9pm to 10pm second Saturday of
every month, if His Sufficiency feels like meeting with you, otherwise
never". (Though, to be fair, you could probably represent that with a
simple "Never" and it'd be just as correct.)

It's worth noting that pure seconds can easily be used as timedeltas.
If you want your form to be convertible back and forth with a number
of seconds, it's easy enough to subtract two datetimes by their Unix
times. But before defining the class, it's essential to define what
you want to do with it. Not all operations are equally meaningful.

ChrisA