[Numpy-discussion] Changing the datetime operation unit rules

[Mark Wiebe]

On Tue, Jun 7, 2011 at 4:47 PM, Dave Hirschfeld
<dave.hirschfeld at gmail.com>wrote:

> Mark Wiebe <mwwiebe <at> gmail.com> writes:
>
> >
> > >>> a = np.datetime64('today')
> >
> > >>> a - a.astype('M8[Y]')
> >
> > numpy.timedelta64(157,'D')
> >
> > vs
> >
> >
> > >>> a = np.datetime64('today')
> > >>> a - a.astype('M8[Y]')
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > TypeError: ufunc subtract cannot use operands with types
> dtype('datetime64[D]') and dtype('datetime64[Y]')
> >
> >
> > Cheers,
> > Mark
> >
> >
>
> I think I like the latter behaviour actually. The first one implicitly
> assumes
> I want the yearly frequency converted to the start of the period. I think
> the
> user should have to explicitly convert the dates to a common representation
> before performing arithmetic on them.
>

I'm thinking of a datetime as an infinitesimal moment in time, with the unit
representing the precision that can be stored. Thus, '2011', '2011-01', and
'2011-01-01T00:00:00.00Z' all represent the same moment in time, but with a
different unit of precision. Computationally, this perspective is turning
out to provide a pretty rich mechanism to do operations on date.

A time period is a different beast, and conceptually consists of a
(datetime, timedelta) tuple or two sequential datetimes together.

It seems to me that if you didn't want your data to be silently cast to the
> start of the period it would be very difficult to determine if this had
> happened or not.
>
> As an example consider the pricing of a stock using the black-scholes
> formula.
> The value is dependant on the time to maturity which is the expiry date
> minus
> the current date. If the expiry date was accidentally specified at (or
> converted
> to) a monthly frequency and the current date was a daily frequency taking
> the
> difference will give you the wrong number of days until expiry resulting in
> a
> subtly different answer - not good.
>

A timeseries library layer on top of datetime should be able to do
appropriate type checking to ensure things are done safely. If that's not
the case with the current design, I think the functionality that would
enable that should be explored.

NB: The timeseries Date/DateArray have a day_of_year attribute which is very
> useful.
>

What I like about the above computation is that day_of_year is trivial to
implement as a one-liner, not needing a specialized function or attribute at
the bottom library layer.

Cheers,
Mark


>
> Regards,
> Dave
>
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110607/0359f936/attachment.html>