[Datetime-SIG] What's are the issues?

Tim Peters tim.peters at gmail.com
Wed Jul 29 05:13:12 CEST 2015


[Chris Angelico <rosuav at gmail.com>]
> What if the existing timedelta is left as-is,

That much isn't a "what if" - that much is a requirement ;-)

> and a new calendardelta type is introduced? Instead of folding
> everything down to a simple microsecond count, it would retain
> the exact values it was given,
> so calendardelta(days=1) != calendardelta(seconds=86400).
> When you add a calendardelta to an aware datetime, it performs
> what you're describing as calendar arithmetic

That's what the _current_ timedelta already does (things like "same
time tomorrow", "same time in 25000 weeks", and "same time plus an
hour 57 days ago" are all trivially done already by datetime +
timedelta operations).

What Lennart is on about is that there's no direct way to spell "the
other" kind of arithmetic now (operationally defined by:  convert to
UTC first, then do the "naive arithmetic", and finally convert back to
the original timezone).

But it's also straightforward to write a simple function to do that,
and not every simple function has to be built in.

> and it will be the most plausibly sane behaviour for the exact unit used; so,
> for instance, adding calendardelta(days=1) would never affect the hour/minute/second
> shown, unless it would otherwise create an illegal time. Would that serve?

Note that timedelta doesn't accept any units for which there are any
questions about what a "calendar operation" "should do" in Guido's
"naive time" design.  That's also an intentional part of the datetime
design.  So. e.g., you can ask a timedelta for some number of days or
weeks, but _not_ for some number of months or years.  "Why not years?"
is because there's one case where what to do isn't 100% obvious to
everyone:  a year starting from a leap year's 29 Feb.  "Why not a
month?" has many more questionable cases.

In any case, you should look at other Python date-&-time libraries
(like mxDateTime and dateutil) because there are already approaches to
richer "calendar options" fully thought out.


More information about the Datetime-SIG mailing list