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.

"Loris Bennett" <loris.bennett@fu-berlin.de> 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.bennett@fu-berlin.de

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" <loris.bennett@fu-berlin.de> 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.bennett@fu-berlin.de

On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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'.

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: lal@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" <loris.bennett@fu-berlin.de> 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.bennett@fu-berlin.de

On 2022-04-14 16:22, Jon Ribbens via Python-list wrote:
> On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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).

On Thu, 14 Apr 2022 at 19:16, MRAB <python@mrabarnett.plus.com> 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.

On Fri, 15 Apr 2022 at 03:45, Marco Sulla <Marco.Sulla.Python@gmail.com> wrote:
>
> On Thu, 14 Apr 2022 at 19:16, MRAB <python@mrabarnett.plus.com> 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

On 2022-04-14, MRAB <python@mrabarnett.plus.com> wrote:
> On 2022-04-14 16:22, Jon Ribbens via Python-list wrote:
>> On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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.

On Fri, 15 Apr 2022 at 00:54, Loris Bennett <loris.bennett@fu-berlin.de> 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

On 2022-04-14 15:22:29 -0000, Jon Ribbens via Python-list wrote:
> On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
> On 2022-04-14 15:22:29 -0000, Jon Ribbens via Python-list wrote:
>> On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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.

On 2022-04-16, Jon Ribbens <jon+usenet@unequivocal.eu> wrote:
> On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> 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!

On 2022-04-16 13:47:32 -0000, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
> > On 2022-04-14 15:22:29 -0000, Jon Ribbens via Python-list wrote:
> >> On 2022-04-14, Paul Bryan <pbryan@anode.ca> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2022-04-16 14:22:04 -0000, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Jon Ribbens <jon+usenet@unequivocal.eu> wrote:
> > On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer <hjp-python@hjp.at> wrote:
>
> On 2022-04-16 14:22:04 -0000, 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

On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer <hjp-python@hjp.at> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer <hjp-python@hjp.at> wrote:
>
> On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer <hjp-python@hjp.at> 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

On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer <hjp-python@hjp.at> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
> On 2022-04-16 13:47:32 -0000, 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.

On Sun, 17 Apr 2022 at 03:52, Peter J. Holzer <hjp-python@hjp.at> wrote:
>
> On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer <hjp-python@hjp.at> 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

On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer <hjp-python@hjp.at> 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.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On Sun, 17 Apr 2022 at 05:38, Peter J. Holzer <hjp-python@hjp.at> wrote:
>
> On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer <hjp-python@hjp.at> 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

On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
> On 2022-04-16 14:22:04 -0000, Jon Ribbens via Python-list wrote:
>> On 2022-04-16, Jon Ribbens <jon+usenet@unequivocal.eu> wrote:
>> > On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> 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.

On Sat, 16 Apr 2022 20:35:22 -0000 (UTC), Jon Ribbens
<jon+usenet@unequivocal.eu> 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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/