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