Pre-Pre-PEP: The datetime.timedeltacal class

Chris Angelico rosuav at gmail.com
Sun Apr 17 06:13:13 EDT 2022


On Sun, 17 Apr 2022 at 18:17, Peter J. Holzer <hjp-python at 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-python at 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


More information about the Python-list mailing list