[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