[Numpy-discussion] timezones and datetime64

[Chris Barker - NOAA Federal]

On Tue, Apr 2, 2013 at 2:39 PM, Pauli Virtanen <pav at iki.fi> wrote:

> As far as I understand (more knowledgeable people, please correct me),
> Numpy's datetime handling in 1.7 is timezone-agnostic and works in UTC
> (which is not a time zone). That is, datetime64 represents an absolute
> point in time, and "2013-04-02T05:00:00-0100",

thanks Pauli -- actually, after writting that message, I realized that
it looks like datetime64 doesn't know a thing about timezones of any
sort, anyway, anyhow.

rather, what it does is apply timezones on I/O -- when creating a new
datetime64 or when writing out (in text format, anyway). So really,
it's not very smart.

> So it's rather unlike datetime.datetime. I can see the reasons why it
> was designed as it is now --- the problems seem similar to Unicode on
> Python 3, the encoding/decoding is painful to get right especially as
> the timezones are a mess due to historical reasons.

yup -- a real nightmare.

> The above design seems philosophically at odds with the concept of a
> "naive" datetime type. A "naive" datetime is sort of datetime64[D] plus
> HH:MM:SS, but not quite.

actually, I think datetime64 is naive -- the problem is entirely the I/O

> I think your point about using current timezone in interpreting user
> input being dangerous is probably correct ---

Thanks -- I'm convinced it's a really bad idea.

-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