On Sat, Mar 29, 2014 at 1:04 PM, Nathaniel Smith <n...@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.bar...@noaa.gov
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
