[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