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

[Jon Ribbens]

On 2022-04-16, Peter J. Holzer <hjp-python at 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.