<br><br><div class="gmail_quote">On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I was working on adding some test cases in numpy for the argmin/max functions with some datetime64s.  I found that on my 32-bit machine, it fails to parse a date past the Y2.038k date.  I find this odd because the datetime is supposed to be 64-bits, but I guess there is some arch-dependent code somewhere?<br>



<br></blockquote></div><div><br>I think that is actually POSIX for the time_t structure. Which is not to say it's good ;) Google UNIX Year 2038 problem. ISTR reading recently that there is a movement afoot to fix the time_t structure on 32 bit machines for Linux. You've got to wonder, what were the POSIX people thinking?<br>

<br></div></div></blockquote><div><br>See comments <a href="http://lwn.net/Articles/457089/">here</a>.<br><br>Chuck <br></div></div>