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

[Chris Barker - NOAA Federal]

On Wed, Aug 14, 2013 at 10:35 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:

Hi Mark, great to have you thinking (and coding) about this!

>> - Marc also commented that making datetime64 time-zone naive would be
>> "the easy way"
>
> I've experimented a little bit with one possibility in this direction within
> dynd. Basically, adding a time zone to the metadata which initially only can
> be UTC or abstract. (I'm calling it "abstract" because I don't think "naive"
> communicates the right idea about it.)

I like that term better, too -- I only borrowed "naive" from the
stdlib datetime docs.

And having these two is good -- saves us the argument of which to do


>  I'm -1 on simply removing a
> distinction between UTC and abstract ISO 8601 strings, I think equivocating
> the two would be as bad as the current situation.

well, I wouldn't equate them (or did you mean equate, thought that
would be equivocating...), I'd say one or the other if you couldnt' do
both. though I"m still confused about the difference if you don't
provide any other time zone capability.

> Adding a limited timezone
> with just these two options might be a way to improve the situation without
> too much development effort, while maintaining a clear path to proper
> timezone support.

yup -- though my concern is that calling a datetime64 "UTC" may imply
that there is some other time zone functionality in there -- which
there isn't (at least not yet) i.e. it's really jsut a hint ot the
user as to how it should be thought of (and makes it clear what to do
when you parse an ISO sting with an offset...)

> In this formulation, strings without a timezone are parsed as abstract
> datetimes, and strings with a timezone as UTC datetimes, without allowing
> implicit conversions:

>>>> from dynd import nd, ndt
>>>> nd.array('2011-03-22T12:00', dtype='datetime("min")')
> nd.array(2011-03-22T12:00, datetime<unit=minute,tz=abstract>)
>>>> nd.array('2011-03-22T12:00Z', dtype='datetime("min", "UTC")')
> nd.array(2011-03-22T12:00Z, datetime<unit=minute,tz=utc>)
>>>> nd.array('2011-03-22T12:00Z', dtype='datetime("min")')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "_pydynd.pyx", line 892, in _pydynd.w_array.__cinit__
> (_pydynd.cxx:5774)
> RuntimeError: cannot parse "2011-03-22T12:00Z" as an abstract datetime using
> rule "strict", because a timezone was present in the string
>>>> nd.array('2011-03-22T12:00', dtype='datetime("min", "UTC")')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "_pydynd.pyx", line 892, in _pydynd.w_array.__cinit__
> (_pydynd.cxx:5774)
> RuntimeError: cannot parse "2011-03-22T12:00" as a datetime with timezone
> using
> rule "strict", because no timezone was present in the string

This is looking good to me.

> I've also implemented one way of getting a more relaxed parsing mode, with
> the parameter that controls casting strictness. Note that in this case it is
> throwing away the timezone information, so the "-0400" doesn't get
> incorporated in the third value.
>
>>>> nd.array(['2011-03-22T12:00', '2012-04-23T01:00Z',
>>>> '2012-05-01T13:00-0400'])
> nd.array([2011-03-22T12:00, 2012-04-23T01:00, 2012-05-01T13:00],
> strided_dim<convert<to=datetime<unit=minute,tz=abstract>, from=string,
> errmode=none>>)

hmm -- it is explicite, but still seems fragile to me -- one coudl
test with "Z" and 0, and then  later get a different offset and things
would go tot heck -- but buyer beware with a non-default setting, I
guess.

> This stuff is all experimental/work in progress, but if you want to try
> these examples you can install Anaconda and use its conda package manager to
> update the package dynd-python.
> (https://github.com/ContinuumIO/dynd-python/blob/master/README.md#trying-out-dynd).

Great, thanks!

Any prospects of something similar in numpy relatively soon?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov