[Numpy-discussion] Default unit for datetime/timedelta

[Mark Wiebe]

On Thu, Jun 9, 2011 at 4:17 AM, Dave Hirschfeld
<dave.hirschfeld at gmail.com>wrote:

> Mark Wiebe <mwwiebe <at> gmail.com> writes:
>
> >
> > Here are some current behaviors that are inconsistent with the
> microsecond
> default, but consistent with the "generic time unit" idea:
> >
> > >>> np.timedelta64(10, 's') + 10
> > numpy.timedelta64(20,'s')
> >
> >
>
> That is what I would expect (and hope) would happen. IMO an integer should
> be
> cast to the dtype ([s]) of the datetime/timedelta.
>
> >
> > >>> np.array(['2011-03-12T13', '2012'], dtype='M8')
> > array(['2011-03-12T13:00:00.000000-0600',
> '2011-12-31T18:00:00.000000-0600'],
> dtype='datetime64[us]')
> >
>
> I would expect the second value of the array to be midnight at the end of
> the
> year. I'm not sure what is actually happening in the above example. What
> happens
> if I email that code to someone in New Zealand would they get a different
> array??


They will get exactly the same result as you do under the hood for the
second one, but it will print differently with the local timezone printing
convention. With the timezone encoded in the string as it is, that string
does represent midnight at the start of the year in UTC. To get the same
result for the first one, you would specify '2011-03-12T13Z', indicating the
time is in UTC instead of local time.

-Mark


>
> -Dave
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110609/af11dced/attachment.html>