[Numpy-discussion] Default unit for datetime/timedelta

Mark Wiebe mwwiebe at gmail.com
Thu Jun 9 16:06:45 EDT 2011


On Thu, Jun 9, 2011 at 1:38 AM, Pierre GM <pgmdevlist at gmail.com> wrote:

>
> On Jun 9, 2011, at 2:22 AM, Mark Wiebe wrote:
> > > > >>> 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]')
> > >
> > > Why is the second one not '2012-01-01T00:00:00-0600' ?
> > >
> > > This is because dates are stored at midnight UTC, and when converted to
> local time for the default time-based printing, that changes slightly.
> > > ISO8601 specifies to interpret an input in local time if no "Z" or
> timezone offset is given, so that's why the first one matches. I haven't
> been able to think of a way around it other than putting warnings in the
> documentation, and have made 'today' and 'now' throw errors if you try to
> use them as times or dates respectively.
> >
> > I see the logic, but I don't like it at all. I would expect the date to
> be stored in the local time zone by default (that is, if no other time zone
> info is available).
> >
> > It's not satisfying to me either, but I haven't been able to think of a
> solution I like. The idea of converting from 'D' to 's' metadata depending
> on the timezone setting of your computer feels worse to me than the current
> approach, but if someone has an idea that's better I'm all ears.
>
> A simpler approach could be to drop ISO8601 recommendation and assume that
> any single datetime is expressed in UTC by default. Managing time zones
> would then be let to some specific subclass...


Doing nothing with time zones would mean this prints by default:

 >>> np.datetime_as_string(np.datetime64('now'))
'2011-06-09T20:03:20Z'

instead of this:

>>> np.datetime64('now')
numpy.datetime64('2011-06-09T15:03:28-0500','s')

The issue above is the relationship between dates and datetimes, which the
NumPy datetime64 has in a continuum. From a UTC perspective, this is very
natural, but it does cause a few hiccups. I'll make a thread at some point
for discussing the time zone issues.

-Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110609/3fb8337e/attachment.html>


More information about the NumPy-Discussion mailing list