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

[Matthew Brett]

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