On 2022-04-16, Peter J. Holzer <hjp-pyt...@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. -- https://mail.python.org/mailman/listinfo/python-list