[Numpy-discussion] timezones and datetime64
lists at hilboll.de
Wed Apr 3 00:56:03 EDT 2013
>> 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?
More information about the NumPy-Discussion