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.
Looking again at the NEP, I see "business day" as a time unit, then
below, that "B" is interpreted as "24h, 1440m, 86400s" i.e. a day.
This seems like a really bad idea -- it implies that you can convert
from business day to hours, and back again, but, of course, if you do:
start_date + n business_days
You should not get the same thing as:
start_date + (n * 24) hrs
which is why I think that a "business day" is not really a unit -- it is
a specification for a Calendar operation.
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.
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?
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.
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.
-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@noaa.gov