[Python-Dev] Status on PEP-431 Timezones
chris.barker at noaa.gov
Mon Jul 27 21:18:49 CEST 2015
On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> I think using the word 'naive' is both inaccurate and a mistake.
> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.
In this context "naive" means "having no knowledge of timezone". And it
does make some sense as a word to use in that case. I don't like it much,
but it's the term used in the datetime module docs, so there you go.
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.
But really, the points Tim was making are not about timezones at all -- but
about two concepts:
Time arithmetic with:
1) Time spans (timedeltas) -- this is an "amount" of time, and can be
added, subtracted, etc to a datetime. such time spans have various
appropriate units, like seconds, days. weeks -- but, as Tim pointed out,
"years" is NOT an appropriate unit of timedeltas, and should not be allowed
in any lib that uses them.
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
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev