[Numpy-discussion] Dates and times and Datetime64 (again)

Chris Barker chris.barker at noaa.gov
Sat Mar 29 16:56:14 EDT 2014


On Sat, Mar 29, 2014 at 1:04 PM, Nathaniel Smith <njs at pobox.com> wrote:

> > 1- You give as an example of "naive" datetime handling:
> >
> >>>> np.datetime64('2005-02-25T03:00Z')
> > np.datetime64('2005-02-25T03:00')
> >
> > This IIUC is incorrect. The Z modifier is a timezone offset, and for
> normal
> > "naive" datetimes would cause an error.
>

I think this is somewhat open for discussion -- yes, it's odd, but in the
spirit of practicality beats purity, it seems OK. We could allow any TZ
specifier for that matter -- that's kind of how "naive" or "local" timezone
(non) handling works -- it's up to the user to make sure that all DTs are
in the same timezone. All it would be doing is tossing out some additional
information that was in the ISO string.

If we are explicitly calling it UTC-always, then anything other than Z or
00:00 (or nothing) would need to be converted.

I think when it comes down to it, anything other than "proper" timezone
handling will require these user-beware compromises.


As a separate issue, we might decide that we want to continue to allow
> "Z" modifiers (or all offset modifiers) temporarily in numpy, to avoid
> breaking code without warning.


Maybe the best tactic -- though it's broken enough now that I'm not sure it
matters. A clear direction from here may be a better bet.

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140329/f87faa7e/attachment.html>


More information about the NumPy-Discussion mailing list