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

[Loris Bennett]

Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> <loris.bennett at fu-berlin.de> declaimed the following:
>
>>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
>
> 	The Explanatory Supplement to the Astronomical Almanac (table 15.3)
> defines the /day/ as 24hrs->1440mins->86400secs	BUT		defines the Julian
> /year/ as 365.25 days.

That is interesting.  However, I am not claiming that the definition of
a year as 365 24-hour days is in any way correct, merely that it is a
possible definition and one that is potentially handy if one wants to
represent large numbers of seconds in a more readable way.

> 	It goes on to also give (for my copy -- length of year at 1990):
> Tropical (equinox to equinox)		365.2421897 days *
> Sidereal (fixed star to fixed star)	365.25636 days
> Anomalistic (perihelion to perihelion)	365.25964 days
> Eclipse (moon's node to moon's node)	346.26005
> Gaussian (Kepler's law /a/=1)		365.25690
> Julian								365.25
>
> 	Length of the month (I interpret this as lunar month):
> Synodic (new moon to new moon)	29.53059 days
> Tropical (as with year)				27.32158
> Sidereal (as with year)				27.32166
> Anomalistic (perigee to perigee)	27.55455
> Draconic (node to node)				27.21222
>
> *	I /think/ this is the year used for leap-day calculations, and why some
> leap centuries are skipped as it is really less than a quarter day per
> year, so eventually one gets to over-correcting by a day.
>
> 	Of course, this book also has a footnote giving the speed of light as
> 1.80261750E12 Furlongs/Fortnight <G>

And of course I should have been asking why timedelta doesn't provide an
easy way to format the period as a number of fortnights :-)

> 	However, as soon you incorporate units that are not SI seconds you have
> to differentiate between pure duration (based on SI seconds) and civil time
> (which may jump when leap seconds are added/subtracted, time zones are
> crossed, or daylight savings time goes into [or out of] effect).
>
> 	For the most part, Python's datetime module seems to account for civil
> time concepts, not monotonic durations. 

That indeed seems to be the case and the lack of trivial formatting
options for monotonic durations is what surprises me. 

> 	The Ada standard separates "duration" (as a measure of elapsed time, in
> fixed point seconds) from "time" (a private type in Ada.Calendar -- which
> does NOT define hours/minutes... It has Year 1901..2399, Month 1..12, Day
> 1..31, Day_duration 0.0..86400.0). There are functions to create a Time
> from components, split a Time into components, compare two times, add a
> Duration to a Time, subtract a Duration from a Time, and subtract a Time
> from a Time (getting a Duration). Oh, and a function to get Time from
> system clock. Per the standard, the Time Zone used is implementation
> defined (so one needs to read the implementation manual to find out what a
> Time really notates). Of note:
> """
> 26.a/1
> To be honest: {8652/0106} {AI95-00160-01} By "proper date" above we mean
> that the given year has a month with the given day. For example, February
> 29th is a proper date only for a leap year. We do not mean to include the
> Seconds in this notion; in particular, we do not mean to require
> implementations to check for the “missing hour” that occurs when Daylight
> Savings Time starts in the spring. 
> """
> """
> 43
>    type Duration is delta implementation-defined range
> implementation-defined;
> """
>
> 	GNAT provides an extension package GNAT.Calendar that adds
> hour/minute/day-of-week and some other utilities... BUT
> """
>  procedure Split_At_Locale
>      (Date       : Ada.Calendar.Time;
>       Year       : out Ada.Calendar.Year_Number;
>       Month      : out Ada.Calendar.Month_Number;
>       Day        : out Ada.Calendar.Day_Number;
>       Hour       : out Hour_Number;
>       Minute     : out Minute_Number;
>       Second     : out Second_Number;
>       Sub_Second : out Second_Duration);
>  --  Split a standard Ada.Calendar.Time value in date data (Year, Month,
> Day)
>    --  and Time data (Hour, Minute, Second, Sub_Second). This version of
> Split
>    --  utilizes the time zone and DST bias of the locale (equivalent to
> Clock).
>    --  Due to this simplified behavior, the implementation does not require
>    --  expensive system calls on targets such as Windows.
>    --  WARNING: Split_At_Locale is no longer aware of historic events and
> may
>    --  produce inaccurate results over DST changes which occurred in the
> past.
> """
-- 
This signature is currently under construction.