02.04.2013 22:42, Chris Barker - NOAA Federal kirjoitti:
[clip]
> As I poke at this a bit, I"m noticing that maybe time zones aren't
> handles at all internally -- rather, the conversion is done to UTC
> when creating a datetime64, and conversion is then done to the locale
> when creating a strng representation -- maybe nothing inside at all.
>> Does the timezone info survive saving in npz, etc?
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",
"2013-04-02T04:00:00-0200", ... are represented by the same (on the
binary-level) datetime64 value. In particular no timezone information is
stored, see "datetime_array.view(np.uint64)", as it is not needed.
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.
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.
***
I think your point about using current timezone in interpreting user
input being dangerous is probably correct --- perhaps UTC all the way
would be a safer (and simpler) choice?
--
Pauli Virtanen