[Numpy-discussion] fixing up datetime
Mon Jun 6 14:31:07 CDT 2011
On Mon, Jun 6, 2011 at 1:33 PM, Christopher Barker <Chris.Barker@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.
> 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
> 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
> Christopher Barker, Ph.D.
> 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
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion