I wish it were. It seems unreasonably difficult to get constructive feedback. Chris is pretty much the only one making the attempt and that discussion petered out. I don't use datetime64 much myself, probably what we need is a developer who does use that facility. Any volunteers?
Chuck On Tue, Aug 13, 2013 at 6:45 PM, Matthew Brett <[email protected]>wrote: > Hi, > > On Mon, Aug 12, 2013 at 4:16 PM, Chris Barker - NOAA Federal > <[email protected]> wrote: > > 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. > > Is it easy to identify who is currently developing against datetime64 in > numpy? > > Do you think it is possible to get rough consensus within this group? > > Cheers, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
