On Thu, Jun 9, 2011 at 4:17 AM, Dave Hirschfeld <dave.hirschf...@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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
