[Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

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.
>
<snip>

> '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
lib?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

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...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/5647f43b/attachment.html>