On Thu, Mar 20, 2014 at 7:27 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> On Thu, Mar 20, 2014 at 4:16 AM, Nathaniel Smith <n...@pobox.com> wrote: > >> Your NEP suggests making all datetime64s be in UTC, and treating string >> representations from unknown timezones as UTC. How does this differ from, >> and why is it superior to, making all datetime64s be naive? >> >> This came up in the conversation before -- I think the fact is that a > 'naive' datetime and a UTC datetime are almost exactly the same. In essence > you can use a UTC datetime and pretend it's naive in almost all cases. > > The difference comes down to I/O. > It is more than I/O. It is also about interoperability with Python's datetime module. Here is the behavior that I don't like in the current implementation: >>> d = array(['2001-01-01T12:00'], dtype='M8[ms]') >>> d.item(0) datetime.datetime(2001, 1, 1, 17, 0) If I understand NEP correctly, the proposal is to make d.item(0) return >>> d.item(0).replace(tzinfo=timezone.utc) datetime.datetime(2001, 1, 1, 12, 0, tzinfo=datetime.timezone.utc) instead. But this is not what I would expect: I want >>> d.item(0) datetime.datetime(2001, 1, 1, 12, 0) When I work with naive datetime objects I don't want to be exposed to timezones at all.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
