[Numpy-discussion] Default unit for datetime/timedelta
Mark Wiebe
mwwiebe@gmail....
Thu Jun 9 15:08:55 CDT 2011
On Thu, Jun 9, 2011 at 4:17 AM, Dave Hirschfeld
<dave.hirschfeld@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@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110609/af11dced/attachment-0001.html
More information about the NumPy-Discussion
mailing list