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

Nathaniel Smith njs at pobox.com
Sat Mar 29 16:04:03 EDT 2014


On Fri, Mar 28, 2014 at 9:30 PM, Sankarshan Mudkavi
<smudkavi at 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



More information about the NumPy-Discussion mailing list