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... _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
