[Datetime-SIG] Calendar vs timespan calculations...

[Lennart Regebro]

Sorry, catching up with the posts, here, as the mailing list was
created when I was asleep.
So I'm cutting and pasting from the archives...

Chris Barker chris.barker at noaa.gov:
> [that a day is always 24 hours] it's not an assumption, it's a definition.

Right, but that's like defining Pi to be three. It's not in accordance
to reality, and therefore it causes a lot of problems.

> What is currently supported by the datetime module, and I think Tim is
> referring to as "naive" time operations: adding, subtracting, units of time
> along the theoretical time axis.

Well, that is supported, yes, but only for datetimes that does not
have a time zone, or that has a time zone with a fixed offset. It is
NOT supported for datetimes with a time zone of the type that people
typically live in: One whose offset changes from time to time. In
practice, pretty much all of them except UTC.

That means if you want to do these operations, you have to first
convert the datetime to UTC, then do the arithmetic and then convert
it back.

> Then there are what I am calling "calendar" operations -- these are
> operations that only make sense with a calendar (and, in fact a timezone, I
> think). this is operations like: "the same time two days later" -- this is
> not the same as moving two days (48 hrs) along the time axis -- it simply
> is not.

Right. These operations *are* in fact supported, but in a limited
fashion. There is no support for months or years, notably. You can add
days, hours, minutes and seconds, but you have to be aware then that
you can end up with datetimes that does not actually exist, or are
ambiguous, ie times that happens twice.

I wish it was as you assumed it was, because that would have been much
easier to fix, as you say, we can have add the "calendar" operations
into a separate package, and yes, that is indeed what dateutil's
"relativedelta" does, amongst some other things.

It might be possible to add a real time delta in a separate package as
well, I haven't looked into that.

> Given all the ugliness of DST and changing time zones, and all that, UTC is
> the lingua franca of time -- time zones are defined by how the are offset
> from UTC, and in UTC (as in naive), math is relatively easy. So the best
> way to handle time zones is to store and manipulate everything in UTC, and
> then convert to/from the calendar representation using the time zone, when
> the user needs (or provides).

Yes, that would indeed have been the simple and obvious way to
implement it, but datetime stores everything in the local zone, which
makes it a lot more complex, as you get things like ambiguous times
and non-existent times when you do that.

//Lennart