On Thu, Mar 20, 2014 at 7:27 PM, Chris Barker <chris.barker@noaa.gov> wrote:

On Thu, Mar 20, 2014 at 4:16 AM, Nathaniel Smith <njs@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.