[Numpy-discussion] About ready to start 1.8 release process.

[Charles R Harris]

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 <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Mon, Aug 12, 2013 at 4:16 PM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
> > On Mon, Aug 12, 2013 at 3:14 PM, Charles R Harris
> > <charlesr.harris at gmail.com> 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
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130813/0599a7e2/attachment.html>