<div class="gmail_quote">On Mon, Jun 6, 2011 at 1:33 PM, Christopher Barker <span dir="ltr"><<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Mark Wiebe wrote:<br>
> I'm wondering if removing the business-day unit from datetime64, and<br>
> adding a business-day API would be a good approach to support all the<br>
> things that are needed?<br>
<br>
</div>That sounds like a good idea to me -- and perhaps it could be a general<br>
Calendar Functions API, to handle other issues as well.<br>
<br><snip><br>
<br>
My thought is that a datetime should not be able to be expressed in<br>
units like business days. A timedelta should, but then there needs to be<br>
a Calendar(i.e. a set of rules) associated with it, and it should be<br>
clearly distinct from "linear unit" timedeltas.<br></blockquote><div> </div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Business days aside, I also see that months and years are given<br>
"Interpreted as" definitions:<br>
<br>
Code Â  Â Interpreted as<br>
Y Â  Â  Â  12M, 52W, 365D<br>
M Â  Â  Â  4W, 30D, 720h<br>
<br>
This is even self inconsistent:<br>
<br>
1Y == 365D<br>
<br>
1Y == 12M == 12 * 30D == 360D<br>
<br>
1Y == 12M == 12 * 4W == 12 * 4 * 7D == 336D<br>
<br>
1Y == 52W == 52 * 7D == 364D<br>
<br>
Is it not clear from this what a mess of mis-interpretation might result<br>
from all that?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In thinking more, numpy's needs are a little different that the netcdf<br>
standards -- netcdf is a way to transmit and store information -- some<br>
of the key problems that come up is that people develop tools to do<br>
things with the data that make assumptions. For instance, my tools that<br>
work with CF-compliant netcdf pretty much always convert the "time" axis<br>
(expresses as time_units since a_datetime) into python datetime objects,<br>
and then go from there.<br>
<br>
This goes to heck is the data is expressed in something like "months<br>
since 1995-01-01"<br>
<br>
Because months are only defined on a Calendar.<br></blockquote><div><br></div><div>Here's what the current implementation can do with that one:</div><div><br></div><div><div>>>> np.datetime64('1995-01-01', 'M') + 13</div>
<div>numpy.datetime64('1996-02','M')</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Anyway, this kind of thing may be less of an issue because we use numpy<br>
to write the tools, not to store and share the data, so hopefully, the<br>
tool author knows what she/he is working with. But I still think the<br>
distinction between linear, convertible, time units, and time units that<br>
vary depending on where you are on which calendar, and what calendar you<br>
are using, should be kept clearly distinct.<br></blockquote><div><br></div><div>Yeah, I'm still working out something that strikes a balance for all these concepts.</div><div><br></div><div>-Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
<br>
-Chris<br>
<br>
<br>
<br>
<br>
--<br>
Christopher Barker, Ph.D.<br>
Oceanographer<br>
<br>
Emergency Response Division<br>
NOAA/NOS/OR&R Â  Â  Â  Â  Â  Â <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959</a> Â  voice<br>
7600 Sand Point Way NE Â  <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329</a> Â  fax<br>
Seattle, WA Â 98115 Â  Â  Â  <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317</a> Â  main reception<br>
<br>
<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br>