On Sun, 17 Apr 2022 at 18:17, Peter J. Holzer <hjp-pyt...@hjp.at> wrote: > > On 2022-04-17 06:08:54 +1000, Chris Angelico wrote: > > On Sun, 17 Apr 2022 at 03:37, Peter J. Holzer <hjp-pyt...@hjp.at> wrote: > > > Datetime arithmetic in the real world is typically not done in seconds, > > > but in calendaric units: Hours, days, weeks, months, years, ... > > > The problem is that several of these have varying lengths: > > > > > > * 1 minute may be 60 or 61 seconds (theoretically also 59, but that > > > hasn't happened yet). > > > * 1 day can be 23, 24 or 25 hours (unless you are in Troll, Antarctica, > > > where it's even weirder). > > > > I think Troll still only has days that consist of 23-25 hours; the > > weird part is that they move their clocks forward for Oslo's summer, > > which is their winter. > > According to Wikipedia they switch between UTC+2 and UTC+0, so the > switchover days would be 22 and 26 hours, respectively.
Ah, hmm. I'll have to play around with the Antarctica/Troll timezone a bit, but it could be that they track Oslo time when only Norwegians are there, and UTC when there are others? In any case, there are *plenty* of bizarre cases. Whether Troll itself is one of those or not, there certainly is no shortage of weird changeover to be found. > > > Subtracting a timedeltacal object from a datetime is the same, just in > > > the opposite direction. > > > > > > Note that t + d - d is in general not equal to t. > > > > By "in general", do you mean "there will be some odd exceptions", or > > "this is usually going to be unequal"? > > The former. Okay, cool. My lengthy explanation of the question was unnecessary then :) > > Isn't that the exact same thing as saying that t + d - d == t? > > No, because the overflow handling isn't reversible. > > > Or are you saying that, when you subtract two timestamps, you can > > never get one of the odd exceptions that would cause problems? > > Yes. > Perfect then. So if I've understood correctly, what you're looking for is a thing that can be added onto a timezone-aware datetime which will have the semantics of adding onto each component individually, and then normalizing. That seems internally consistent, and useful. It's also a natural continuation of Python's migration from "datetime kinda sorta supports timezones, but only if you get a third-party package" to "datetime actually does support timezones" (in the same way that Pike and PostgreSQL do). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
