<br><br>On Sunday, September 18, 2011, Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>><br>><br>> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <<a href="mailto:ben.root@ou.edu">ben.root@ou.edu</a>> wrote:<br>
>><br>>> 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>><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>> Chuck<br>><br>><br><br>Actually, I am quite familiar with the problem, having tried to convince people that there are users of time_t who need it for data archive systems (think digitizing pre-1900 weather obs), but to no avail.<br>
<br>There is a time64_t type that explicitly uses 64 bits.  Don't know if it is a magic bullet, but given that numpy's type is called datetime64, it might be good to explicitly use time64_t.<br><br>Ben Root