<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 3, 2015 at 8:23 AM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@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 dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 11:19 AM, Chris Barker - NOAA Federal <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">If you want that, use tics or numpy.datetime64.</div></blockquote></div><div class="gmail_extra"><br></div></span>Chris, please stop promoting numpy.datetime64 here.  It is definitely not a positive example of how a date/time manipulation library should be designed.<br></div></div></blockquote><div><br></div><div>Sorry -- didn't mean to promote -- and yes, it's actually really horrible, particularly for anything to do with time zones. The point was that there are other ways to get performance for datetime arithmetic if that's what you need. That's all.</div><div><br></div><div>-Chris</div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>