On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy <tjreedy@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 lib?



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