[Chris Barker]
... and infact, everything Tim said can also apply to UTC time. We've had a lot of discussion on teh numpy list about the difference between UTC and "naive" times, but for practicle putrposes, they are exactly the same -- unitl you try to convert to a known time zone anyway.
Yes, "naive arithmetic" is "correct" (by everyone's definition) in any time zone that has a fixed-for-all-eternity offset from UTC. UTC is the simplest case of that (with offset 0). So for all practical purposes you can think of a naive datetime as being "the time" in any eternally-fixed-offset time zone you like - or as in no time zone at all (the time zone _concept_ isn't necessary to grasp naive time - it only takes effort to _forget_ it). But the paranoid should consider that nothing can stop governments from changing the definition of UTC (or any other time zone). They'll have to pry your naive datetimes out of your computer's cold, dead disk drives though ;-)
... 2) Calendar time arithmetic: this is things like "next year", "next week", "two years from now" -- these are quite tricky, and in some special cases have no obvious clear definition (leap years, etc...).
Calendar manipulations like (2) should be kept completely separate from time span manipulation. Is anyone suggesting adding that to the standard lib?
It comes up, and would be useful to many. But it's the kind of thing waiting for an extension module to take the world by storm. If people think the bikeshedding in _this_ thread is excessive ... ;-)