[Numpy-discussion] Dates and times and Datetime64 (again)

[Chris Barker]

On Thu, Mar 20, 2014 at 4:16 AM, Nathaniel Smith <njs at 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. If it's UTC, then an ISO 8601 string
created from it would include a "Z" on the end (or a +0.00, I think),
whereas naive datetime should have no TZ indicator.

On input, the question is what do you do with an ISO string with a TZ
indicator:
   1) translate to UTC  -- make sense is we have the "always UTC" definition
   2) raise an exception  -- makes sense if we have the naive definition
   3) ignore it -- which would make some sense if  were naive, but perhaps
a little too prone to error.


But the real issue with the current implementation is how an iso string
with no TZ indicator is handled -- it currently assumes that means "use the
localle TZ", which is more than not wrong, and clearly subject to errors.

Also, it time-shifts to locale TZ when creating an ISO string, with no way
to specify that.

So:

* I'm not sure what the new NEP is suggesting at all, actually, we need a
fully description, with exampel sof what varios input / ouput would give.

* I think there are more or less three options:
   1)  a) don't have any timezone handling at all -- all datetime64s are
UTC. Always
         b) don't have any timezone handling at all -- all datetime64s are
naive
             (the only difference between these two is I/O of strings, and
maybe I/O of datetime objects with a time zone)
    2) Have a time zone associated with the array -- defaulting to either
UTC or None, but don't provide any implementation other than the tagging,
with the ability to add in TZ handler if you want (can this be
done efficiently?)
    3) Full on proper TZ handling.

I think (3) is off the table for now.

I think (2) is what the NEP proposes, but I'd need more details, examples
to know.

I prefer 1(b), but 1(a) is close enough that I'd be happy with that, too.

Writing this made me think of a third option -- tracking, but no
real manipulation, of TZ. This would be analogous to the ISO 8601 does --
all it does is note an offset. A given DateTime64 array would have a given
offset assigned to it, and the appropriate addition and subtraction would
happen at I/O. Offset of 0.00 would be UTC, and there would be a None
option for naive.

I haven't thought that out for the inevitable complications, though.

-CHB





















> -n
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140320/b6f88a28/attachment.html>