4 ms·
It's 2038, not 2037.[1] (Specifically, January 19th, 2038 at 3:14:08am.) And while lots of systems will be 64-bit, many programs still won't be -- and it seem
by bcantrill 14y ago
It's 2038, not 2037.[1] (Specifically, January 19th, 2038 at 3:14:08am.) And while lots of systems will be 64-bit, many programs still won't be -- and it seems highly likely that this will be a significantly more serious and widespread problem than, say, Y2K or DST. (And certainly more serious than leap seconds, which happen relatively frequently.) Then again, I might be biased: perhaps I'm secretly hoping to spend the years leading up to 2038 paying for my retirement with high-priced consulting gigs to fix it...
[1] http://en.wikipedia.org/wiki/Year_2038_problem http://en.wikipedia.org/wiki/Year_2038_problem
- el_presidente 14y agohttp://article.gmane.org/gmane.linux.kernel/1184914 http://article.gmane.org/gmane.linux.kernel/1184914 Less than a year ago there were already people thinking about your job security. (It's a better explanation than "the glibc maintainers are insane".)
- kabdib 14y agoBut MUCH less than a year ago, many more people were still writing 32-bit-dirty time_t based code. It's gonna be a fun one.