It's 2038, not 2037.[1] (Specifically, January 19th, 2038 at 3:14:08am.) And whi... | Hacker News

Hacker Newsnew | past | comments | ask | show | jobs | submit

		bcantrill on July 1, 2012 \| parent \| context \| favorite \| on: Leap second causing Linux server crashes? 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

el_presidente on July 1, 2012 [–]

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 on July 1, 2012 | [–]

But 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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact