Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Dennis Lee Bieber writes:
> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> 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
> Julian365.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
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
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Random832 writes: > On Tue, Apr 19, 2022, at 07:11, Loris Bennett 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 > > A timedelta *is* a pure period. A timedelta of one day is 86400 > seconds. > > The thing you *think* timedelta does [making a day act as 23 or 25 > hours across daylight saving boundaries etc], that you *don't* want it > to do, is something it *does not actually do*. I don't know how this > can be made more clear to you. I have now understood this. > timedelta is what you need. if you think it's not, it's because you're > using datetime incorrectly. It is what I need. It just doesn't do the trivial format conversion I (apparently incorrectly) expected. However, I can implement the format conversion myself. [snip (35 lines)] -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Tue, Apr 19, 2022, at 07:11, Loris Bennett 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
A timedelta *is* a pure period. A timedelta of one day is 86400 seconds.
The thing you *think* timedelta does [making a day act as 23 or 25 hours across
daylight saving boundaries etc], that you *don't* want it to do, is something
it *does not actually do*. I don't know how this can be made more clear to you.
timedelta is what you need. if you think it's not, it's because you're using
datetime incorrectly.
The real problem is that naive datetime objects [without using either a fixed
timezone offset like the built-in utc, or a library like pytz] are not fit for
any purpose.
If you use pytz correctly [which is unfortunately awkward due to leaky
abstractions and mismatches between the datetime model works and how most
people expect datetimes with timezones to work], you will indeed get 24 hours
from timedelta(days=1)
>>> et = pytz.timezone('America/New_York')
>>> et.normalize(et.localize(datetime.datetime(2022,3,12,12,0,0)) +
>>> datetime.timedelta(days=1))
datetime.datetime(2022, 3, 13, 13, 0, tzinfo=)
you can see here that 2022-03-12T12:00-0500 + timedelta(days=1) correctly
becomes 2022-03-13T13:00-0400, 24 hours later.
As far as I know, Python doesn't even have a way to represent "1 day" [or 1
month, 1 year] as a context-dependent-length interval (the thing you think
timedelta does), at least not within the standard library and the datetime
model.
> 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).
>
> It is obviously fairly easy to rustle up something to do this, but I am
> surprised that this is not baked into Python (such a class also seems to
> be missing from R). 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.
>
> Cheers,
>
> Loris
>
> --
> This signature is currently under construction.
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-19, Barry wrote: >> On 19 Apr 2022, at 19:38, Dennis Lee Bieber wrote: >> *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. > > Leap century is skip unless it’s a leap quadra century. Indeed, which is why "leap=not year & 3" works for years in range(1901, 2100). Which I have found useful before when programming in an assembly language that has no division operation ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
> On 19 Apr 2022, at 19:38, Dennis Lee Bieber wrote: > > *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. Leap century is skip unless it’s a leap quadra century. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-19 19:23, Dennis Lee Bieber wrote: On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett" 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. So, a /day/ is a solar day, as distinct from a sidereal day. What's the difference? Well, a "sidereal day" is how long it takes for the Earth to rotate on its axis, but as it's also orbiting the Sun in the same direction, midday won't happen until a little later, hence "solar day". [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
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.
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
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.
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.
"""
--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Wed, 20 Apr 2022 at 02:16, Loris Bennett 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Jon Ribbens writes: > On 2022-04-19, Loris Bennett wrote: >> 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). > > Well, that's my point. Everyone's all in their own slightly-different > little niches. There isn't one straightforward standard that makes all > or even most of them happy. I'm sure you're right. I just strikes me as a little odd that so much effort has gone into datetime to make things work (almost) properly for (almost) everyone, whereas timedelta has remained rather rudimentary, at least in terms of formatting. It seems to me that periods on the order of hours would have quite generic applications, but maybe that's just the view from my niche. Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-19, Loris Bennett wrote: > 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). Well, that's my point. Everyone's all in their own slightly-different little niches. There isn't one straightforward standard that makes all or even most of them happy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-19, Loris Bennett wrote: > Jon Ribbens writes: >> On 2022-04-19, Loris Bennett 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Jon Ribbens writes: > On 2022-04-19, Loris Bennett 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 >> It is obviously fairly easy to rustle up something to do this, but I am >> surprised that this is not baked into Python (such a class also seems to >> be missing from R). > > 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. Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-19, Loris Bennett 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. > It is obviously fairly easy to rustle up something to do this, but I am > surprised that this is not baked into Python (such a class also seems to > be missing from R). I would be very surprised if any language supported the arbitrary format above you happen to be interested in! > 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Jon Ribbens writes: > On 2022-04-19, Loris Bennett wrote: >> Jon Ribbens writes: >>> On 2022-04-19, Loris Bennett 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
"Peter J. Holzer" writes:
> On 2022-04-16 20:35:22 -, Jon Ribbens via Python-list wrote:
>> On 2022-04-16, Peter J. Holzer wrote:
>> > On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
>> >> ... although now having looked into the new 'zoneinfo' module slightly,
>> >> it really should have a giant red flashing notice at the top of it
>> >> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
>> >>
>> >> Suppose we do this:
>> >>
>> >> >>> import datetime, zoneinfo
>> >> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
>> >> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>> >> >>> print(d)
>> >> 2020-10-31 12:00:00-07:00
>> >> >>> d1 = d + datetime.timedelta(days=1)
>> >> >>> print(d1)
>> >> 2020-11-01 12:00:00-08:00
>> >>
>> >> d1 is *wrong*.
>> >
>> > No, this is correct. That's the result you want.
>>
>> I can categorically guarantee you it is not. But let's put it a
>> different way, if you like, if I want to add 24 hours, i.e. 86,400
>> seconds (or indeed any other fixed time period), to a timezone-aware
>> datetime in Python, how do I do it?
>
> What you *should* be able to do is use datetime.timedelta(hours=24).
>
> Unfortunately, you can't, because somebody decided to add a
> normalization rule to timedelta which turns this into timedelta(days=1,
> hours=0).
>
>> It would appear that, without converting to UTC before doing the
>> calculation, you can't.
>
> When doing calculations of this kind I frankly prefer converting to
> "seconds since the epoch" and doing simple arithmetic. (Yes, leap
> seconds, I know .. I just ignore those)
>
>
>> > So why didn't this work for me (I also used Python 3.9)? My guess is
>> > that astimezone() doesn't pick the correct time zone.
>>
>> astimezone() doesn't pick a time zone at all. It works out the current
>> local offset from UTC.
>
> The timezone object it returns also includes a timezone string ("CET" in
> my example). So it's not *just* the offset. The result is misleading,
> though. You get something which looks like it's a timezone object for
> Central European Time, but isn't.
>
>> It doesn't know anything about when or if that
>> offset ever changes.
>
> astimezone() doesn't have to. It just has to pick the correct timezone
> object. That object then knows about offset changes.
>
>
>> >> timedelta(days=1) is 24 hours (as you can check by
>> >> calling timedelta(days=1).total_seconds() ),
>> >
>> > It shouldn't be. 1 Day is not 24 hours in the real world.
>>
>> Nevertheless, timedelta is a fixed time period so that is the only
>> definition possible.
>
> Yeah, you keep repeating that. I think we are talking at cross-purposes
> here. You are talking about how timedelta is implemented while I'm
> talking what semantics it *should* have.
>
>
>> >> It appears that with Python it's not so much a guideline as an
>> >> absolute concrete rule, and not because programmers will introduce
>> >> bugs, but because you need to avoid bugs in the standard library!
>> >
>> > As a programmer you must always adapt to the problem. Saying "I must do
>> > it the wrong way because my library is buggy" is just lazy.
>>
>> I didn't say any of that. I said you must do it the conservative way,
>> and it's not "my library" that's buggy, it's the language's built-in
>> *standard library* that's buggy.
>
> With "your library" I meant "the library you have" not "the library you
> wrote". And while having a buggy (or just badly designed) standard
> library is especially annoying, you still aren't forced to use it if if
> doesn't fit your needs.
>
> hp
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).
It is obviously fairly easy to rustle up something to do this, but I am
surprised that this is not baked into Python (such a class also seems to
be missing from R). 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.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16 20:35:22 -, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer wrote:
> > On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
> >> ... although now having looked into the new 'zoneinfo' module slightly,
> >> it really should have a giant red flashing notice at the top of it
> >> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
> >>
> >> Suppose we do this:
> >>
> >> >>> import datetime, zoneinfo
> >> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
> >> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
> >> >>> print(d)
> >> 2020-10-31 12:00:00-07:00
> >> >>> d1 = d + datetime.timedelta(days=1)
> >> >>> print(d1)
> >> 2020-11-01 12:00:00-08:00
> >>
> >> d1 is *wrong*.
> >
> > No, this is correct. That's the result you want.
>
> I can categorically guarantee you it is not. But let's put it a
> different way, if you like, if I want to add 24 hours, i.e. 86,400
> seconds (or indeed any other fixed time period), to a timezone-aware
> datetime in Python, how do I do it?
What you *should* be able to do is use datetime.timedelta(hours=24).
Unfortunately, you can't, because somebody decided to add a
normalization rule to timedelta which turns this into timedelta(days=1,
hours=0).
> It would appear that, without converting to UTC before doing the
> calculation, you can't.
When doing calculations of this kind I frankly prefer converting to
"seconds since the epoch" and doing simple arithmetic. (Yes, leap
seconds, I know .. I just ignore those)
> > So why didn't this work for me (I also used Python 3.9)? My guess is
> > that astimezone() doesn't pick the correct time zone.
>
> astimezone() doesn't pick a time zone at all. It works out the current
> local offset from UTC.
The timezone object it returns also includes a timezone string ("CET" in
my example). So it's not *just* the offset. The result is misleading,
though. You get something which looks like it's a timezone object for
Central European Time, but isn't.
> It doesn't know anything about when or if that
> offset ever changes.
astimezone() doesn't have to. It just has to pick the correct timezone
object. That object then knows about offset changes.
> >> timedelta(days=1) is 24 hours (as you can check by
> >> calling timedelta(days=1).total_seconds() ),
> >
> > It shouldn't be. 1 Day is not 24 hours in the real world.
>
> Nevertheless, timedelta is a fixed time period so that is the only
> definition possible.
Yeah, you keep repeating that. I think we are talking at cross-purposes
here. You are talking about how timedelta is implemented while I'm
talking what semantics it *should* have.
> >> It appears that with Python it's not so much a guideline as an
> >> absolute concrete rule, and not because programmers will introduce
> >> bugs, but because you need to avoid bugs in the standard library!
> >
> > As a programmer you must always adapt to the problem. Saying "I must do
> > it the wrong way because my library is buggy" is just lazy.
>
> I didn't say any of that. I said you must do it the conservative way,
> and it's not "my library" that's buggy, it's the language's built-in
> *standard library* that's buggy.
With "your library" I meant "the library you have" not "the library you
wrote". And while having a buggy (or just badly designed) standard
library is especially annoying, you still aren't forced to use it if if
doesn't fit your needs.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16, Dennis Lee Bieber wrote: > On Sat, 16 Apr 2022 20:35:22 - (UTC), Jon Ribbens > declaimed the following: >>I can categorically guarantee you it is not. But let's put it a >>different way, if you like, if I want to add 24 hours, i.e. 86,400 >>seconds (or indeed any other fixed time period), to a timezone-aware >>datetime in Python, how do I do it? It would appear that, without >>converting to UTC before doing the calculation, you can't. > > Which is probably the recommended means to do just that. Yes, as I've already mentioned it is good advice to always use UTC when doing date/time calculations and only convert to another timezone for display. However it is somewhat surprising that Python's datetime simply *does not work* when doing arithmetic on timezone-aware objects. It's not "disrecommended", it's straight-up broken. > The only thing that is most noticeable about UTC is the incorporation > of leap-seconds. I've never yet managed to find an application where leap-seconds matter ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sun, 17 Apr 2022 at 08:37, Dennis Lee Bieber wrote: > And proposals to make > DST permanent year round -- so "noon" (1200hrs) is not "noon" (sun at > zenith) pretty much anywhere. > Noon isn't precisely zenith anyway, for several reasons: 1) Time zones synchronize their clocks on the mean noon at some location. Usually that's approximately close to the most populous part of the region, but not always - for instance, all of China is on one timezone, despite spanning 4-5 hours' worth of solar noon. 2) Solar noon migrates around a bit during the year. I don't remember the exact figures, but if you want to read a sundial with any precision, you need to take a date-based adjustment. 3) Solar days aren't all 24 hours long anyway. The clock and calendar should *roughly* correspond to the sun, in that broadly speaking, 2AM will be in darkness and 2PM will be in sunlight, and the solstices will land in June and December. But down to the minute, it's much more useful to synchronize on atomic time than astronomical. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sat, 16 Apr 2022 20:35:22 - (UTC), Jon Ribbens declaimed the following: >I can categorically guarantee you it is not. But let's put it a >different way, if you like, if I want to add 24 hours, i.e. 86,400 >seconds (or indeed any other fixed time period), to a timezone-aware >datetime in Python, how do I do it? It would appear that, without >converting to UTC before doing the calculation, you can't. > Which is probably the recommended means to do just that. UTC is an international standard (call it a zero-reference). All other time-zones (and daylight savings time) tend to be local/civil time entities (even if widely accepted), subject to change by whim of the government (consider, just in the US alone, there are some states, or even parts of states, that do not honor the DST change over [I really don't know how my watch would handle some of those, since it time-syncs with WWV-B, including shifting to DST when WWV-B includes the flag in its broadcast]). And proposals to make DST permanent year round -- so "noon" (1200hrs) is not "noon" (sun at zenith) pretty much anywhere. The only thing that is most noticeable about UTC is the incorporation of leap-seconds. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16, Peter J. Holzer wrote:
> On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
>> On 2022-04-16, Jon Ribbens wrote:
>> > On 2022-04-16, Peter J. Holzer wrote:
>> >> Python missed the switch to DST here, the timezone is wrong.
>> >
>> > Because you didn't let it use any timezone information. You need to
>> > either use the third-party 'pytz' module, or in Python 3.9 or above,
>> > the built-in 'zoneinfo' module.
>>
>> ... although now having looked into the new 'zoneinfo' module slightly,
>> it really should have a giant red flashing notice at the top of it
>> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
>>
>> Suppose we do this:
>>
>> >>> import datetime, zoneinfo
>> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>> >>> UTC = zoneinfo.ZoneInfo('UTC')
>> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>> >>> print(d)
>> 2020-10-31 12:00:00-07:00
>> >>> d1 = d + datetime.timedelta(days=1)
>> >>> print(d1)
>> 2020-11-01 12:00:00-08:00
>>
>> d1 is *wrong*.
>
> No, this is correct. That's the result you want.
I can categorically guarantee you it is not. But let's put it a
different way, if you like, if I want to add 24 hours, i.e. 86,400
seconds (or indeed any other fixed time period), to a timezone-aware
datetime in Python, how do I do it? It would appear that, without
converting to UTC before doing the calculation, you can't.
> So why didn't this work for me (I also used Python 3.9)? My guess is
> that astimezone() doesn't pick the correct time zone.
astimezone() doesn't pick a time zone at all. It works out the current
local offset from UTC. It doesn't know anything about when or if that
offset ever changes.
>> timedelta(days=1) is 24 hours (as you can check by
>> calling timedelta(days=1).total_seconds() ),
>
> It shouldn't be. 1 Day is not 24 hours in the real world.
Nevertheless, timedelta is a fixed time period so that is the only
definition possible.
>> then it can pretend timezones don't exist and do 'naive' arithmetic.
>
> On the contrary. When a datetime is timezone aware, it must use that
> timezone's rules. Adding one day to a datetime just before a DST switch
> must add 23 or 25 hours, not 24. This is NOT naive.
But it is. It's adding 24 hours and while it's doing so it's naively
assuming that the UTC offset doesn't change during that period. Then
once it's got that naive result it's labelling it with what it thinks
is the timezone data at that time.
Here's another example to prove the point:
>>> LONDON = zoneinfo.ZoneInfo('Europe/London')
>>> d0 = datetime.datetime(2022, 3, 27, 0, tzinfo=LONDON)
>>> print(d0)
2022-03-27 00:00:00+00:00
>>> print(d0 + datetime.timedelta(seconds=3600+1800))
2022-03-27 01:30:00+00:00
That is impossible - 2022-03-27 01:30 is a time that *doesn't exist*
in the Europe/London timezone. At 01:00 the clocks moved instantly
to 02:00 as daylight savings kicked in. So the following is wrong too:
>>> print(d0 + datetime.timedelta(seconds=3600*2))
2022-03-27 02:00:00+01:00
That's not 2 hours after midnight, that's 1 hour after midnight.
Doing the calculations in UTC works of course:
>>> print((d0.astimezone(UTC) +
datetime.timedelta(seconds=3600+1800)).astimezone(LONDON))
2022-03-27 02:30:00+01:00
>>> print((d0.astimezone(UTC) +
datetime.timedelta(seconds=3600*2)).astimezone(LONDON))
2022-03-27 03:00:00+01:00
> (There is an ambiguity, though: Should 2021-03-27T12:00 CEST -
> 2021-03-26T12:00 CET return 1 day or 25 hours? Both results are correct,
> and depending on context you might prefer one or the other).
But if you're returning that result as a timedelta then only "25 hours"
is correct (or indeed "1 day 3,600 seconds"), because for a timedelta a
day is 24 hours *by definition*.
>> There is a general guideline that you should always keep and use your
>> datetimes as UTC, only ever using timezones for the purposes of display.
>> Usually this is because it keeps things simpler for the programmer, and
>> hence they are less likely to introduce bugs into their programs.
>
> While I generally do this (and often preach it to my collegues) it must
> be stated that this is only a GENERAL guide line.
Yes, that's what I just said.
>> It appears that with Python it's not so much a guideline as an
>> absolute concrete rule, and not because programmers will introduce
>> bugs, but because you need to avoid bugs in the standard library!
>
> As a programmer you must always adapt to the problem. Saying "I must do
> it the wrong way because my library is buggy" is just lazy.
I didn't say any of that. I said you must do it the conservative way,
and it's not "my library" that's buggy, it's the language's built-in
*standard library* that's buggy.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sun, 17 Apr 2022 at 05:38, Peter J. Holzer wrote: > > On 2022-04-17 02:46:38 +1000, Chris Angelico wrote: > > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote: > > > For adding a datetime and timedelta I think the answer is clear. > > > But subtracting two datetimes is ambiguous. > > > > > > > But if the difference between two datetimes is a timedelta, then > > surely adding a timedelta to a datetime should give the other > > datetime? It's just as ambiguous. > > To answer the same question in a different way: > > No, because the timedelta object is overspecified when applied to a > specific datetime (when you start at 2022-04-16T21:29, it doesn't matter > whether you add 7 days or 168 hours) but that extra information matters > with different starting points. When you subtract two specific > datetimes, there is no way to extract that extra information. So > addition and subtraction are not symmetrical. > Ah, that's fair. So what you're really saying is that the difference between two datetimes *isn't* a timedelta, but when we subtract them and get back a timedelta, we're throwing away information for simplicity. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote: > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote: > > For adding a datetime and timedelta I think the answer is clear. > > But subtracting two datetimes is ambiguous. > > > > But if the difference between two datetimes is a timedelta, then > surely adding a timedelta to a datetime should give the other > datetime? It's just as ambiguous. To answer the same question in a different way: No, because the timedelta object is overspecified when applied to a specific datetime (when you start at 2022-04-16T21:29, it doesn't matter whether you add 7 days or 168 hours) but that extra information matters with different starting points. When you subtract two specific datetimes, there is no way to extract that extra information. So addition and subtraction are not symmetrical. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16, Peter J. Holzer wrote: > On 2022-04-16 13:47:32 -, Jon Ribbens via Python-list wrote: >> That's impossible unless you redefine 'timedelta' from being, as it is >> now, a fixed-length period of time, to instead being the difference >> between two specific dates and times in specific timezones. Days and >> months have different lengths depending on when and where you are. > > That's what I would have expected it to be. Otherwise, why bother with a > class when a simple float suffices? > > Date arithmetic isn't simple. You need complex data types to implement > it correctly. > >> >> It's an undocumented feature of timedelta that by 'day' it means '86400 >> >> seconds'. >> > >> > I'd call that a bug, not a feature: >> >> It's the only possible way of implementing it, > > It's definitely not the only possible way of implementing it. It's the only possible way of implementing a fixed time period, which is what timedelta is (modulo the bugs in 'datetime' I mentioned in my other post). >> > Python missed the switch to DST here, the timezone is wrong. >> >> Because you didn't let it use any timezone information. > > I used astimezone() and it returned something something that Python > calls "timezone aware" containing time zone information which is > correct for that time and my location > (tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET')). Why > should I expect a "timezone aware" datetime to not be actually timezone > aware? I think by "timezone aware" it doesn't mean "timezone aware", it means "has a specified fixed offset from UTC". Yes this is distinctly sub-optimal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sun, 17 Apr 2022 at 03:52, Peter J. Holzer wrote: > > On 2022-04-17 02:46:38 +1000, Chris Angelico wrote: > > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote: > > > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote: > > > > So which one is it? Which one do you get when you add days=7 to a > > > > datetime? > > > > > > For adding a datetime and timedelta I think the answer is clear. > > > But subtracting two datetimes is ambiguous. > > > > > > > But if the difference between two datetimes is a timedelta, then > > surely adding a timedelta to a datetime should give the other > > datetime? > > Not necessarily. You might compute the difference for another purpose. > If you compute a change rate from two gauge readings you would compute > something like (r1 - r0) / (t1 - t0). You don't intend to add (t1 - t0) > to any timestamp, so that property would be irrelevant. However, you do > want something which can be used in a division and which has a > consistent unit (so one could argue that you don't want a timedelta > object at all, but a floating point number). > True, but logically, it's hard to explain arithmetic when (x - y) + x != y. ( And yes, I'm aware that floats can violate that, but the discrepancy isn't a good thing.) Your example definitely wants to be measured in UTC, though. It wants to ignore silly changes of clocks, and just show the amount of time that passed. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote: > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote: > > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote: > > > So which one is it? Which one do you get when you add days=7 to a > > > datetime? > > > > For adding a datetime and timedelta I think the answer is clear. > > But subtracting two datetimes is ambiguous. > > > > But if the difference between two datetimes is a timedelta, then > surely adding a timedelta to a datetime should give the other > datetime? Not necessarily. You might compute the difference for another purpose. If you compute a change rate from two gauge readings you would compute something like (r1 - r0) / (t1 - t0). You don't intend to add (t1 - t0) to any timestamp, so that property would be irrelevant. However, you do want something which can be used in a division and which has a consistent unit (so one could argue that you don't want a timedelta object at all, but a floating point number). hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote: > > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote: > > On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote: > > > On the contrary. When a datetime is timezone aware, it must use that > > > timezone's rules. Adding one day to a datetime just before a DST switch > > > must add 23 or 25 hours, not 24. This is NOT naive. > > > > > > (There is an ambiguity, though: Should 2021-03-27T12:00 CEST - > > > 2021-03-26T12:00 CET return 1 day or 25 hours? Both results are correct, > > > and depending on context you might prefer one or the other). > > > > > > > That's exactly the problem. A day IS 24 hours *and* it is the time > > period required for you to get to the same clock on the following > > date. It's fundamentally ambiguous. > > > > Let's take this out of Python altogether for a moment. Imagine that > > it's 9AM Thursday. You say to your friend, hey, let's meet up again, > > same time next week. Are you planning to meet 168 hours later, or at > > 9AM the following Thursday? > > > > OF COURSE you mean 168 hours later. That's what "next week" means. > > Of course NOT. It means that only in 50 out of 52 weeks. A 4% error rate > is more than enough to make me acutely aware that it isn't true in > general. Also, won't count off 168 hours but look at my calendar/clock. > > > > OF COURSE you're meeting at 9AM the following Thursday. That's what > > "next week" means. > > This. Certainly when meeting a friend. Almost certainly when dealing > with humans (if they are in a different time zone we may have to agree > on a time zone for "same time"). For a technical process I *might* > simplify "1 week" to "168 hours", but only if the spec gives me > sufficient leeway. > > > > And they can't both be true if DST is changing. > > > > So which one is it? Which one do you get when you add days=7 to a datetime? > > For adding a datetime and timedelta I think the answer is clear. > But subtracting two datetimes is ambiguous. > But if the difference between two datetimes is a timedelta, then surely adding a timedelta to a datetime should give the other datetime? It's just as ambiguous. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-17 02:14:44 +1000, Chris Angelico wrote: > On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote: > > On the contrary. When a datetime is timezone aware, it must use that > > timezone's rules. Adding one day to a datetime just before a DST switch > > must add 23 or 25 hours, not 24. This is NOT naive. > > > > (There is an ambiguity, though: Should 2021-03-27T12:00 CEST - > > 2021-03-26T12:00 CET return 1 day or 25 hours? Both results are correct, > > and depending on context you might prefer one or the other). > > > > That's exactly the problem. A day IS 24 hours *and* it is the time > period required for you to get to the same clock on the following > date. It's fundamentally ambiguous. > > Let's take this out of Python altogether for a moment. Imagine that > it's 9AM Thursday. You say to your friend, hey, let's meet up again, > same time next week. Are you planning to meet 168 hours later, or at > 9AM the following Thursday? > > OF COURSE you mean 168 hours later. That's what "next week" means. Of course NOT. It means that only in 50 out of 52 weeks. A 4% error rate is more than enough to make me acutely aware that it isn't true in general. Also, won't count off 168 hours but look at my calendar/clock. > OF COURSE you're meeting at 9AM the following Thursday. That's what > "next week" means. This. Certainly when meeting a friend. Almost certainly when dealing with humans (if they are in a different time zone we may have to agree on a time zone for "same time"). For a technical process I *might* simplify "1 week" to "168 hours", but only if the spec gives me sufficient leeway. > And they can't both be true if DST is changing. > > So which one is it? Which one do you get when you add days=7 to a datetime? For adding a datetime and timedelta I think the answer is clear. But subtracting two datetimes is ambiguous. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote: > > On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote: > > timedelta(days=1) is 24 hours (as you can check by > > calling timedelta(days=1).total_seconds() ), > > It shouldn't be. 1 Day is not 24 hours in the real world. > > > but d1 is 25 hours later > > than 'd'. If we do the calculations in UTC instead, it works correctly: > > > > >>> print((d.astimezone(UTC) + > > datetime.timedelta(days=1)).astimezone(LOS_ANGELES)) > > 2020-11-01 11:00:00-08:00 > > > > It seems that Python is assuming that if the tzinfo attributes of two > > datetimes are the same, > > There is only one datetime in your examples. > > > then it can pretend timezones don't exist and do 'naive' arithmetic. > > On the contrary. When a datetime is timezone aware, it must use that > timezone's rules. Adding one day to a datetime just before a DST switch > must add 23 or 25 hours, not 24. This is NOT naive. > > (There is an ambiguity, though: Should 2021-03-27T12:00 CEST - > 2021-03-26T12:00 CET return 1 day or 25 hours? Both results are correct, > and depending on context you might prefer one or the other). > That's exactly the problem. A day IS 24 hours *and* it is the time period required for you to get to the same clock on the following date. It's fundamentally ambiguous. Let's take this out of Python altogether for a moment. Imagine that it's 9AM Thursday. You say to your friend, hey, let's meet up again, same time next week. Are you planning to meet 168 hours later, or at 9AM the following Thursday? OF COURSE you mean 168 hours later. That's what "next week" means. OF COURSE you're meeting at 9AM the following Thursday. That's what "next week" means. And they can't both be true if DST is changing. So which one is it? Which one do you get when you add days=7 to a datetime? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Jon Ribbens wrote:
> > On 2022-04-16, Peter J. Holzer wrote:
> >> Python missed the switch to DST here, the timezone is wrong.
> >
> > Because you didn't let it use any timezone information. You need to
> > either use the third-party 'pytz' module, or in Python 3.9 or above,
> > the built-in 'zoneinfo' module.
>
> ... although now having looked into the new 'zoneinfo' module slightly,
> it really should have a giant red flashing notice at the top of it
> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
>
> Suppose we do this:
>
> >>> import datetime, zoneinfo
> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
> >>> UTC = zoneinfo.ZoneInfo('UTC')
> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
> >>> print(d)
> 2020-10-31 12:00:00-07:00
> >>> d1 = d + datetime.timedelta(days=1)
> >>> print(d1)
> 2020-11-01 12:00:00-08:00
>
> d1 is *wrong*.
No, this is correct. That's the result you want.
So why didn't this work for me (I also used Python 3.9)? My guess is
that astimezone() doesn't pick the correct time zone.
> timedelta(days=1) is 24 hours (as you can check by
> calling timedelta(days=1).total_seconds() ),
It shouldn't be. 1 Day is not 24 hours in the real world.
> but d1 is 25 hours later
> than 'd'. If we do the calculations in UTC instead, it works correctly:
>
> >>> print((d.astimezone(UTC) +
> datetime.timedelta(days=1)).astimezone(LOS_ANGELES))
> 2020-11-01 11:00:00-08:00
>
> It seems that Python is assuming that if the tzinfo attributes of two
> datetimes are the same,
There is only one datetime in your examples.
> then it can pretend timezones don't exist and do 'naive' arithmetic.
On the contrary. When a datetime is timezone aware, it must use that
timezone's rules. Adding one day to a datetime just before a DST switch
must add 23 or 25 hours, not 24. This is NOT naive.
(There is an ambiguity, though: Should 2021-03-27T12:00 CEST -
2021-03-26T12:00 CET return 1 day or 25 hours? Both results are correct,
and depending on context you might prefer one or the other).
> There is a general guideline that you should always keep and use your
> datetimes as UTC, only ever using timezones for the purposes of display.
> Usually this is because it keeps things simpler for the programmer, and
> hence they are less likely to introduce bugs into their programs.
While I generally do this (and often preach it to my collegues) it must
be stated that this is only a GENERAL guide line. There are many
exceptions, especially when scheduling events in the future. For
example, if want to meet somebody on July 18th, 2023 at 19:00 in Vienna,
Austria, it would be wrong to store that date as 2023-07-18T17:00Z. The
EU has decided to abolish DST, and while I don't expect them to get
around to it within the next year (or maybe ever), it might still
happen. So we simply don't know yet whether 19:00 local time will be
17:00 or 18:00 UTC. There have been cases where countries have changed
their DST rules only days in advance.
> It appears that with Python it's not so much a guideline as an
> absolute concrete rule, and not because programmers will introduce
> bugs, but because you need to avoid bugs in the standard library!
As a programmer you must always adapt to the problem. Saying "I must do
it the wrong way because my library is buggy" is just lazy. Use a
different library or write one yourself. (Unless of course the customer
doesn't want to pay for the extra work, then they get what they pay
for.)
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16 13:47:32 -, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer wrote:
> > On 2022-04-14 15:22:29 -, Jon Ribbens via Python-list wrote:
> >> On 2022-04-14, Paul Bryan wrote:
> >> > I think because minutes and hours can easily be composed by multiplying
> >> > seconds. days is separate because you cannot compose days from seconds;
> >> > leap seconds are applied to days at various times, due to
> >> > irregularities in the Earth's rotation.
> >>
> >> That's an argument that timedelta should *not* have a 'days' attribute,
> >> because a day is not a fixed number of seconds long (to know how long
> >> a day is, you have to know which day you're talking about, and where).
> >
> > Which is exactly why timedelta *must* have separate fields for seconds,
> > days and months. You can't simply express the larger units as
> > multiples of the smaller units, so they have to be stored separately for
> > date arithmetic to work.
>
> That's impossible unless you redefine 'timedelta' from being, as it is
> now, a fixed-length period of time, to instead being the difference
> between two specific dates and times in specific timezones. Days and
> months have different lengths depending on when and where you are.
That's what I would have expected it to be. Otherwise, why bother with a
class when a simple float suffices?
Date arithmetic isn't simple. You need complex data types to implement
it correctly.
> >> It's an undocumented feature of timedelta that by 'day' it means '86400
> >> seconds'.
> >
> > I'd call that a bug, not a feature:
>
> It's the only possible way of implementing it,
It's definitely not the only possible way of implementing it. PostgreSQL
for examply has implemented it correctly. I'm quite sure some other
programming languages have, too.
> from datetime import datetime, timedelta
> t0 = datetime.fromisoformat("2022-03-26T12:00").astimezone()
> t0
> > datetime.datetime(2022, 3, 26, 12, 0,
> > tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
> d = timedelta(days=1)
> t1 = t0 + d
> t1
> > datetime.datetime(2022, 3, 27, 12, 0,
> > tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
> t1.isoformat()
> > '2022-03-27T12:00:00+01:00'
> >
> > Python missed the switch to DST here, the timezone is wrong.
>
> Because you didn't let it use any timezone information.
I used astimezone() and it returned something something that Python
calls "timezone aware" containing time zone information which is
correct for that time and my location
(tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET')). Why
should I expect a "timezone aware" datetime to not be actually timezone
aware?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16, Jon Ribbens wrote:
> On 2022-04-16, Peter J. Holzer wrote:
>> Python missed the switch to DST here, the timezone is wrong.
>
> Because you didn't let it use any timezone information. You need to
> either use the third-party 'pytz' module, or in Python 3.9 or above,
> the built-in 'zoneinfo' module.
... although now having looked into the new 'zoneinfo' module slightly,
it really should have a giant red flashing notice at the top of it
saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
Suppose we do this:
>>> import datetime, zoneinfo
>>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>>> UTC = zoneinfo.ZoneInfo('UTC')
>>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>>> print(d)
2020-10-31 12:00:00-07:00
>>> d1 = d + datetime.timedelta(days=1)
>>> print(d1)
2020-11-01 12:00:00-08:00
d1 is *wrong*. timedelta(days=1) is 24 hours (as you can check by
calling timedelta(days=1).total_seconds() ), but d1 is 25 hours later
than 'd'. If we do the calculations in UTC instead, it works correctly:
>>> print((d.astimezone(UTC) +
datetime.timedelta(days=1)).astimezone(LOS_ANGELES))
2020-11-01 11:00:00-08:00
It seems that Python is assuming that if the tzinfo attributes of two
datetimes are the same, then it can pretend timezones don't exist and
do 'naive' arithmetic. This is of course a totally false assumption.
Apparently when making the native version of 'zoneinfo', the lessons
learned from 'pytz' have been discarded.
There is a general guideline that you should always keep and use your
datetimes as UTC, only ever using timezones for the purposes of display.
Usually this is because it keeps things simpler for the programmer, and
hence they are less likely to introduce bugs into their programs. It
appears that with Python it's not so much a guideline as an absolute
concrete rule, and not because programmers will introduce bugs, but
because you need to avoid bugs in the standard library!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-16, Peter J. Holzer wrote:
> On 2022-04-14 15:22:29 -, Jon Ribbens via Python-list wrote:
>> On 2022-04-14, Paul Bryan wrote:
>> > I think because minutes and hours can easily be composed by multiplying
>> > seconds. days is separate because you cannot compose days from seconds;
>> > leap seconds are applied to days at various times, due to
>> > irregularities in the Earth's rotation.
>>
>> That's an argument that timedelta should *not* have a 'days' attribute,
>> because a day is not a fixed number of seconds long (to know how long
>> a day is, you have to know which day you're talking about, and where).
>
> Which is exactly why timedelta *must* have separate fields for seconds,
> days and months. You can't simply express the larger units as
> multiples of the smaller units, so they have to be stored separately for
> date arithmetic to work.
That's impossible unless you redefine 'timedelta' from being, as it is
now, a fixed-length period of time, to instead being the difference
between two specific dates and times in specific timezones. Days and
months have different lengths depending on when and where you are.
>> It's an undocumented feature of timedelta that by 'day' it means '86400
>> seconds'.
>
> I'd call that a bug, not a feature:
It's the only possible way of implementing it, so it can't be a bug.
The documentation could be better though.
from datetime import datetime, timedelta
t0 = datetime.fromisoformat("2022-03-26T12:00").astimezone()
t0
> datetime.datetime(2022, 3, 26, 12, 0,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
d = timedelta(days=1)
t1 = t0 + d
t1
> datetime.datetime(2022, 3, 27, 12, 0,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
t1.isoformat()
> '2022-03-27T12:00:00+01:00'
>
> Python missed the switch to DST here, the timezone is wrong.
Because you didn't let it use any timezone information. You need to
either use the third-party 'pytz' module, or in Python 3.9 or above,
the built-in 'zoneinfo' module.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-14 15:22:29 -, Jon Ribbens via Python-list wrote:
> On 2022-04-14, Paul Bryan wrote:
> > I think because minutes and hours can easily be composed by multiplying
> > seconds. days is separate because you cannot compose days from seconds;
> > leap seconds are applied to days at various times, due to
> > irregularities in the Earth's rotation.
>
> That's an argument that timedelta should *not* have a 'days' attribute,
> because a day is not a fixed number of seconds long (to know how long
> a day is, you have to know which day you're talking about, and where).
Which is exactly why timedelta *must* have separate fields for seconds,
days and months. You can't simply express the larger units as
multiples of the smaller units, so they have to be stored separately for
date arithmetic to work.
> It's an undocumented feature of timedelta that by 'day' it means '86400
> seconds'.
I'd call that a bug, not a feature:
>>> from datetime import datetime, timedelta
>>> t0 = datetime.fromisoformat("2022-03-26T12:00").astimezone()
>>> t0
datetime.datetime(2022, 3, 26, 12, 0,
tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
>>> d = timedelta(days=1)
>>> t1 = t0 + d
>>> t1
datetime.datetime(2022, 3, 27, 12, 0,
tzinfo=datetime.timezone(datetime.timedelta(seconds=3600), 'CET'))
>>> t1.isoformat()
'2022-03-27T12:00:00+01:00'
Python missed the switch to DST here, the timezone is wrong.
If I do the same thing in PostgreSQL:
hjp=> select '2022-03-26T12:00'::timestamptz;
╔╗
║ timestamptz ║
╟╢
║ 2022-03-26 12:00:00+01 ║
╚╝
(1 row)
Time: 5.542 ms
hjp=> select '2022-03-26T12:00'::timestamptz + '1 day'::interval;
╔╗
║?column?║
╟╢
║ 2022-03-27 12:00:00+02 ║
╚╝
(1 row)
It correctly determines that DST is already in effect at noon of March 27th.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-14, MRAB wrote: > On 2022-04-14 16:22, Jon Ribbens via Python-list wrote: >> On 2022-04-14, Paul Bryan wrote: >>> I think because minutes and hours can easily be composed by multiplying >>> seconds. days is separate because you cannot compose days from seconds; >>> leap seconds are applied to days at various times, due to >>> irregularities in the Earth's rotation. >> >> That's an argument that timedelta should *not* have a 'days' attribute, >> because a day is not a fixed number of seconds long (to know how long >> a day is, you have to know which day you're talking about, and where). >> It's an undocumented feature of timedelta that by 'day' it means '86400 >> seconds'. > > When you're working only with dates, timedelta not having a 'days' > attribute would be annoying, especially when you consider that a day is > usually 24 hours, but sometimes 23 or 25 hours (DST). The second half of your sentence is the argument as to why the first half of your sentence is wrong. The difference between noon on the 26th March 2022 in London and noon on the 27th March 2022 is "1 day" from one point of view but is not "1 day" according to timedelta. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Fri, 15 Apr 2022 at 00:54, Loris Bennett wrote:
>
> Hi,
>
> With Python 3.9.2 I get
>
> $ import datetime
> $ s = "1-00:01:01"
> $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
> $ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute,
> seconds=t.second)
> $ d.days
> 1
> $ d.seconds
> 61
> $ d.minutes
> AttributeError: 'datetime.timedelta' object has no attribute 'minutes'
>
> Is there a particular reason why there are no attributes 'minutes' and
> 'hours and the attribute 'seconds' encompasses is the entire fractional
> day?
>
You can get those by dividing:
>>> divmod(d, datetime.timedelta(minutes=1))
(1441, datetime.timedelta(seconds=1))
But the obvious question is: how many minutes ARE there in this time
period? I give a response of 1441 (or if you prefer, 1441 + 1/60 or
roughly 1441.017), but you might just as reasonably consider that
there is one minute.
If a good definition could be chosen, it wouldn't be too hard to add a
bunch of properties to the timedelta that let you view it in other
ways. Otherwise, the easiest way is probably to define yourself a set
of units and sequentially divmod:
>>> units = {"days": datetime.timedelta(days=1), "hours":
>>> datetime.timedelta(hours=1), "minutes": datetime.timedelta(minutes=1),
>>> "seconds": datetime.timedelta(seconds=1)}
>>> for label, unit in units.items():
... n, d = divmod(d, unit)
... print(n, label)
...
1 days
0 hours
1 minutes
1 seconds
>>>
This way, you have full control over which units are "interesting";
for instance, the constructor supports weeks, but a lot of
applications won't consider them to be important, and would prefer to
see "20 days" than "2 weeks and 6 days".
But, as mentioned, adding properties to timedelta would be a
relatively benign change, so it could be done if there's enough need
and a good definition.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Fri, 15 Apr 2022 at 03:45, Marco Sulla wrote: > > On Thu, 14 Apr 2022 at 19:16, MRAB wrote: > > > > When you're working only with dates, timedelta not having a 'days' > > attribute would be annoying, especially when you consider that a day is > > usually 24 hours, but sometimes 23 or 25 hours (DST). > > I agree. Furthermore, timedelta is, well, a time delta, not a date > with a timezone. How could a timedelta take into account DST, leap > seconds etc? It can't. It's a simple representation of a time period. It is useful for situations where you want to express questions like "from this date/time, wait this long, what will the date/time be?". In the absence of a corresponding timezone-aware datetime object, it cannot possibly acknowledge DST. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On Thu, 14 Apr 2022 at 19:16, MRAB wrote: > > When you're working only with dates, timedelta not having a 'days' > attribute would be annoying, especially when you consider that a day is > usually 24 hours, but sometimes 23 or 25 hours (DST). I agree. Furthermore, timedelta is, well, a time delta, not a date with a timezone. How could a timedelta take into account DST, leap seconds etc? About the initial question, I think it's a good question. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-14 16:22, Jon Ribbens via Python-list wrote: On 2022-04-14, Paul Bryan wrote: I think because minutes and hours can easily be composed by multiplying seconds. days is separate because you cannot compose days from seconds; leap seconds are applied to days at various times, due to irregularities in the Earth's rotation. That's an argument that timedelta should *not* have a 'days' attribute, because a day is not a fixed number of seconds long (to know how long a day is, you have to know which day you're talking about, and where). It's an undocumented feature of timedelta that by 'day' it means '86400 seconds'. When you're working only with dates, timedelta not having a 'days' attribute would be annoying, especially when you consider that a day is usually 24 hours, but sometimes 23 or 25 hours (DST). -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
On 2022-04-14, Paul Bryan wrote: > I think because minutes and hours can easily be composed by multiplying > seconds. days is separate because you cannot compose days from seconds; > leap seconds are applied to days at various times, due to > irregularities in the Earth's rotation. That's an argument that timedelta should *not* have a 'days' attribute, because a day is not a fixed number of seconds long (to know how long a day is, you have to know which day you're talking about, and where). It's an undocumented feature of timedelta that by 'day' it means '86400 seconds'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Additionally, which datatype would you expect them to be returned in? One could argument for int or float (Decimal?), both could be valid datatypes, depending on how exact you might want them, while the second is the time base of SI units. Cheers Lars -- Lars Liedtke Software Entwickler Phone: Fax:+49 721 98993- E-mail: l...@solute.de solute GmbH Zeppelinstraße 15 76185 Karlsruhe Germany Marken der solute GmbH | brands of solute GmbH billiger.de | Shopping.de Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten Webseite | www.solute.de Sitz | Registered Office: Karlsruhe Registergericht | Register Court: Amtsgericht Mannheim Registernummer | Register No.: HRB 110579 USt-ID | VAT ID: DE234663798 Informationen zum Datenschutz | Information about privacy policy http://solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php Am 14.04.22 um 17:01 schrieb Paul Bryan: I think because minutes and hours can easily be composed by multiplying seconds. days is separate because you cannot compose days from seconds; leap seconds are applied to days at various times, due to irregularities in the Earth's rotation. On Thu, 2022-04-14 at 15:38 +0200, Loris Bennett wrote: "Loris Bennett" writes: Hi, With Python 3.9.2 I get $ import datetime $ s = "1-00:01:01" $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S") $ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute, seconds=t.second) $ d.days 1 $ d.seconds 61 $ d.minutes AttributeError: 'datetime.timedelta' object has no attribute 'minutes' Is there a particular reason why there are no attributes 'minutes' and 'hours and the attribute 'seconds' encompasses is the entire fractional day? That should read: Is there a particular reason why there are no attributes 'minutes' and 'hours' and the attribute 'seconds' encompasses the entire fractional day? Cheers, Loris -- Dr. Loris Bennett (Herr/Mr) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
I think because minutes and hours can easily be composed by multiplying seconds. days is separate because you cannot compose days from seconds; leap seconds are applied to days at various times, due to irregularities in the Earth's rotation. On Thu, 2022-04-14 at 15:38 +0200, Loris Bennett wrote: > "Loris Bennett" writes: > > > Hi, > > > > With Python 3.9.2 I get > > > > $ import datetime > > $ s = "1-00:01:01" > > $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S") > > $ d = datetime.timedelta(days=t.day, hours=t.hour, > > minutes=t.minute, seconds=t.second) > > $ d.days > > 1 > > $ d.seconds > > 61 > > $ d.minutes > > AttributeError: 'datetime.timedelta' object has no attribute > > 'minutes' > > > > Is there a particular reason why there are no attributes 'minutes' > > and > > 'hours and the attribute 'seconds' encompasses is the entire > > fractional > > day? > > That should read: > > Is there a particular reason why there are no attributes 'minutes' > and > 'hours' and the attribute 'seconds' encompasses the entire > fractional > day? > > > Cheers, > > > > Loris > -- > Dr. Loris Bennett (Herr/Mr) > ZEDAT, Freie Universität Berlin Email > loris.benn...@fu-berlin.de -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
"Loris Bennett" writes: > Hi, > > With Python 3.9.2 I get > > $ import datetime > $ s = "1-00:01:01" > $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S") > $ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute, > seconds=t.second) > $ d.days > 1 > $ d.seconds > 61 > $ d.minutes > AttributeError: 'datetime.timedelta' object has no attribute 'minutes' > > Is there a particular reason why there are no attributes 'minutes' and > 'hours and the attribute 'seconds' encompasses is the entire fractional > day? That should read: Is there a particular reason why there are no attributes 'minutes' and 'hours' and the attribute 'seconds' encompasses the entire fractional day? > Cheers, > > Loris -- Dr. Loris Bennett (Herr/Mr) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de -- https://mail.python.org/mailman/listinfo/python-list
Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Hi, With Python 3.9.2 I get $ import datetime $ s = "1-00:01:01" $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S") $ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute, seconds=t.second) $ d.days 1 $ d.seconds 61 $ d.minutes AttributeError: 'datetime.timedelta' object has no attribute 'minutes' Is there a particular reason why there are no attributes 'minutes' and 'hours and the attribute 'seconds' encompasses is the entire fractional day? Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
