[Numpy-discussion] timezones and datetime64
Chris Barker - NOAA Federal
chris.barker at noaa.gov
Tue Apr 2 19:39:42 EDT 2013
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.
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
Chris.Barker at noaa.gov
More information about the NumPy-Discussion