Dennis Lee Bieber <wlfr...@ix.netcom.com> writes:
> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> <loris.benn...@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.
--
https://mail.python.org/mailman/listinfo/python-list
