[Numpy-discussion] timezones and datetime64

Andreas Hilboll lists@hilboll...
Tue Apr 2 23:56:03 CDT 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?

+1





More information about the NumPy-Discussion mailing list