<div class="gmail_quote">On Thu, Jun 2, 2011 at 1:09 PM, Pierre GM <span dir="ltr"><<a href="mailto:pgmdevlist@gmail.com">pgmdevlist@gmail.com</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"><snip></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> """</div><div class="im">

> A representation is also supported such that the stored date-time<br>
> integer can encode both the number of a particular unit as well as a<br>
> number of sequential events tracked for each unit.<br>
> """<br>
><br>
> I'm not sure I understand what this really means, but I _think_ I agree<br>
> with Pierre that this is unnecessary complication - couldn't it be<br>
> handled by multiple arrays, or maybe a structured dtype?<br>
<br>
</div>My point. Mark W., perhaps you should ask the folks at Enthought (Travis O. in particular) what they had in mind ? Whether the original interest is still there. If it is, I wonder we can't find some workaround that would drop support for that.</blockquote>
<div><br></div><div>I'll ask, for sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>  If we're<br>
> going to allow different units, we might as well have different "origins".<br>
<br>
</div>+1<br>
<div class="im"><br>
><br>
> I also don't think that units like "month", "year", "business day"<br>
> should be allowed -- it just adds confusion. It's not a killer if they<br>
> are defined in the spec:<br>
<br>
-1<br>
</div>In scikits.timeseries, not only did we have years,months and business days, but we also had weeks, that proved quite useful sometimes, and that were discarded in the discussion of the new NEP a few years back.<br></blockquote>
<div><br></div><div>There are weeks in the implementation. One of my points in the original email was whether to adjust week's epoch by a few days so they align with ISO8601 weeks, do you have an opinion about that?</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;">
Anyhow, years and months are simple enough. In case of ambiguities like Mark's example, we can always raise an exception. ISO8601 seems quite OK.<br>
Support for multiple time zones, daylight saving conventions, holidays and so forth could be let to specific packages.<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
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>