On Mon, Aug 12, 2013 at 3:14 PM, Charles R Harris <[email protected]> wrote:
>> > Datetime64 will not be modified in this release. >> >> I now there is neither the time nor the will for all that it needs, >> but please, please, please, can we yank out the broken timezone >> handling at least? >> >> https://github.com/numpy/numpy/issues/3290 > > You need to be a bit more specific, what parts should be yanked out? It's pretty well discussed in issue 3290 -- but what I'm suggesting is essentially to ignore time zones completely -- i.e. make the datetime64 "naive" with respect to time zones. In fact, it already is -- the only timezone handling it has is that if it parses an ISO string and no timezone is specified, it applies the Locale time zone -- this is pretty broken behavior. At the moment, I can't recall what it does with a datetime.datetime instance, but it's not quite consitent with what it does parsing string. I _think_ the only point of contention in that issue 3290 discussion is how datetime64 should parse and ISO string that provides an offset: 1) ignore it -- probably a bad idea 2) raise an error -- you can't do it. 3) apply the offset so that the resulting datetime64 is assumed to be UTC. Personally, I think (2) is the way to go, with the possible addition of allowing zero offset, 'cause, why not? > I'm > also worried about breaking peoples' work arounds this late in the game. well, that is an issue -- though I think most work-arounds will not be broken, and the discussion about this didn't reveal a single user that actually used the "use the Locale time zone" feature -- granted, people contributing to the discussion is a pretty small subset of users. But in 1.7 datetime64 is officially experimental, and keeping a broken implementation around longer will only make for more broken code later. -Chris -- 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 [email protected] _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
