[Python-Dev] Status on PEP-431 Timezones

Tim Peters tim.peters at gmail.com
Mon Jul 27 21:53:24 CEST 2015

[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 ... ;-)

More information about the Python-Dev mailing list