[Numpy-discussion] datetime64 y2k38 bug

Benjamin Root ben.root at ou.edu
Sun Sep 18 23:42:02 EDT 2011

On Sunday, September 18, 2011, Charles R Harris <charlesr.harris at gmail.com>
> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root at ou.edu> wrote:
>> 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?
> 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?
> Chuck

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.

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.

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110918/d782f15b/attachment.html>

More information about the NumPy-Discussion mailing list