On Fri, Mar 28, 2014 at 9:30 PM, Sankarshan Mudkavi
<smudk...@uwaterloo.ca> wrote:
>
> Hi Nathaniel,
>
> 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.
>
>
> If what I understand from reading:
> http://thread.gmane.org/gmane.comp.python.numeric.general/53805
>
> It looks like anything other than Z, 00:00 or UTC that has a TZ adjustment
> would raise an error, and those specific conditions would not (I'm guessing
> this is because we assume it's UTC (or the same timezone) internally,
> anything that explicitly tells us it is UTC is acceptable, although that may
> be just my misreading of it.)If we assume it's UTC, then that's proposal 2, I think :-). My point is just that "naive datetime" already has a specific meaning in Python, and as I understand that meaning, it says that trying to pass a Z timezone to a naive datetime should be an error. 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. Just if we do, then we shoudn't say that this is because we are implementing naive datetimes and this is how naive datetimes work. Instead we should either say that we're not implementing naive datetimes, or else say that we're implementing naive datetimes but have some temporary compatibility hacks on top of that (and probably issue a DeprecationWarning if anyone passes a timezone). -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
