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

[Peter J. Holzer]

On 2022-04-16 13:47:32 -0000, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2022-04-14 15:22:29 -0000, Jon Ribbens via Python-list wrote:
> >> On 2022-04-14, Paul Bryan <pbryan at 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 at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20220416/50d089c7/attachment.sig>