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

Matthew Brett matthew.brett@gmail....
Tue Aug 13 19:45:51 CDT 2013


Hi,

On Mon, Aug 12, 2013 at 4:16 PM, Chris Barker - NOAA Federal
<chris.barker@noaa.gov> wrote:
> On Mon, Aug 12, 2013 at 3:14 PM, Charles R Harris
> <charlesr.harris@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


More information about the NumPy-Discussion mailing list