[Numpy-discussion] fixing up datetime

[Mark Wiebe]

On Mon, Jun 6, 2011 at 1:33 PM, Christopher Barker <Chris.Barker at noaa.gov>wrote:

> Mark Wiebe wrote:
> > I'm wondering if removing the business-day unit from datetime64, and
> > adding a business-day API would be a good approach to support all the
> > things that are needed?
>
> That sounds like a good idea to me -- and perhaps it could be a general
> Calendar Functions API, to handle other issues as well.
>
> <snip>
>
> My thought is that a datetime should not be able to be expressed in
> units like business days. A timedelta should, but then there needs to be
> a Calendar(i.e. a set of rules) associated with it, and it should be
> clearly distinct from "linear unit" timedeltas.
>

I think business day should be removed from timedelta as well, and all this
should be functions operating on the days unit. Having the definition of a
work/trading day be a function parameter instead of a part of a unit
metadata makes this more explicit and eliminates a lot of potential clutter
in the implementation, which has a lot to deal with at that level already.


> Business days aside, I also see that months and years are given
> "Interpreted as" definitions:
>
> Code    Interpreted as
> Y       12M, 52W, 365D
> M       4W, 30D, 720h
>
> This is even self inconsistent:
>
> 1Y == 365D
>
> 1Y == 12M == 12 * 30D == 360D
>
> 1Y == 12M == 12 * 4W == 12 * 4 * 7D == 336D
>
> 1Y == 52W == 52 * 7D == 364D
>
> Is it not clear from this what a mess of mis-interpretation might result
> from all that?
>

This part of the code is used for mapping metadata like [Y/4] -> [3M], or
[Y/26] -> [2W]. I agree that this '/' operator in the unit metadata is
weird, and wouldn't object to removing it.


> In thinking more, numpy's needs are a little different that the netcdf
> standards -- netcdf is a way to transmit and store information -- some
> of the key problems that come up is that people develop tools to do
> things with the data that make assumptions. For instance, my tools that
> work with CF-compliant netcdf pretty much always convert the "time" axis
> (expresses as time_units since a_datetime) into python datetime objects,
> and then go from there.
>
> This goes to heck is the data is expressed in something like "months
> since 1995-01-01"
>
> Because months are only defined on a Calendar.
>

Here's what the current implementation can do with that one:

>>> np.datetime64('1995-01-01', 'M') + 13
numpy.datetime64('1996-02','M')


>
> Anyway, this kind of thing may be less of an issue because we use numpy
> to write the tools, not to store and share the data, so hopefully, the
> tool author knows what she/he is working with. But I still think the
> distinction between linear, convertible, time units, and time units that
> vary depending on where you are on which calendar, and what calendar you
> are using, should be kept clearly distinct.
>

Yeah, I'm still working out something that strikes a balance for all these
concepts.

-Mark


>
>
> -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
> _______________________________________________
> 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/20110606/03b5a10e/attachment.html>