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? Ben Root
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root@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
On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root@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?
See comments here <http://lwn.net/Articles/457089/>. Chuck
On Sun, Sep 18, 2011 at 11:13 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root@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?
See comments here.
<OT> Thanks for the entertaining link " I think it's still perfectly valid to say "you're a moron, and we need to fix it" " (just a quote, doesn't apply to the python community) Josef
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Sep 18, 2011 at 8:52 PM, <josef.pktd@gmail.com> wrote:
On Sun, Sep 18, 2011 at 11:13 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root@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
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
the 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?
See comments here.
<OT>
Thanks for the entertaining link
" I think it's still perfectly valid to say "you're a moron, and we need to fix it" " (just a quote, doesn't apply to the python community)
Josef
I've added a hack to try and work around this problem to the datetime-cleanup pull request: https://github.com/numpy/numpy/pull/161 Basically, for years >= 2038, it uses the year 2036 or 2037 (depending on whether it's a leap year), then adds the year offset back on. Everything already worked fine for me on my 64-bit platform, so it needs testing to confirm the fix works. -Mark
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sunday, September 18, 2011, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root <ben.root@ou.edu> wrote:
I was working on adding some test cases in numpy for the argmin/max
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
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? 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
participants (4)
-
Benjamin Root -
Charles R Harris -
josef.pktd＠gmail.com -
Mark Wiebe