On Thu, Mar 20, 2014 at 11:27 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > * 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.
I think the first goal is to define what a plain vanilla datetime64 does, without any extra attributes. This is for two practical reasons: First, our overriding #1 goal is to fix the nasty I/O problems that default datetime64's show, so until that's done any other bells and whistles are a distraction. And second, adding parameters to dtypes right now is technically messy. This rules out (2) and (3). If we additionally want to keep the option of adding a timezone parameter later, and have the result end up looking like stdlib datetime, then I think 1(b) is the obvious choice. My guess is that this is also what's most compatible with pandas, which is currently keeping its own timezone object outside of the dtype. Any downsides? I guess this would mean that we start raising an error on ISO 8601's with offsets attached, which might annoy some people? > 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. Please no! An integer offset is a terrible way to represent timezones, and hardcoding this would just get in the way of a proper solution. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
