On Sun, Aug 11, 2013 at 4:27 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
>>>> On Wed, Aug 7, 2013 at 3:52 PM, Till Stensitzki <mail.till@gmx.de> wrote:
>>> Hi,
>> there already a plan to release 1.8? I would like to play around with
>> gufuncs.
>>>> No fixed plan I think, but there aren't a lot of blockers:
>https://github.com/numpy/numpy/issues?milestone=1&page=1&state=open. Main
> issue is the timezone handling, but if no one picks that up I'm not sure
> it's really a blocker.
>>I've been looking into that and my inclination at this point is to let it
slide. There are two problems with making changes in the 1.8 release:
backward compatibility and deciding on a solution. Chris mentions that
other project have wrappers to work around the current problems, those
wrappers might break if we change things. And what the change should be
hasn't been decided.
Over the long term I'm inclined to go with solution 1, no timezone. But
could we still do conversions to calender units? If not, how to manage
that. And then how do we manage times that do have timezone information?
For that perhaps we could make a class that uses a naive datetime64
internally, but that adds timezone information, although string parsing
might be a problem since I assume we'd have to check all strings for
consistency.
Related to solution 1 is the question of what lowlevel implementation might
provide the best foundation more specialized classes? Here the thought is
that the low level implementation should make as few assumptions as
possible, but still provide a basis for specialization. For this it would
be nice to get more input from current projects that attempt to use
datetime64.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130811/c30c1331/attachment.html