Hi Chris, > 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.
Yes 2) is indeed what I was suggesting. My apologies for being unclear, I was unsure of how much detail and technical information I should include in the proposal. I will update it and add more examples etc. to actually specify what I mean. I'm not sure how much of a hit the performance would take if we were to take of the Z handler. Do you have any major concerns as of now regarding that, or do you want to wait till I provide more specific details? It also looks like the last option you mentioned seems quite reasonable too. To only do what ISO 8601 does. Perhaps, it would be better to implement that first and then look for an improvement later on? Do you have a preference for this or the option 2) ? I will expand the NEP and hopefully make it clearer what it entails. Once again, thanks for the earlier write up. Cheers, Sankarshan On 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. 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@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.bar...@noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Sankarshan Mudkavi Undergraduate in Physics, University of Waterloo www.smudkavi.com
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
