36 ms·

Fear the Unix 32-bit time-becomes-negative bugs, in 2037. We have 25 years to get ready. I still think we'll be patching at the last minute. (Yeah, lots of sy

by kabdib 14y ago

Fear the Unix 32-bit time-becomes-negative bugs, in 2037. We have 25 years to get ready. I still think we'll be patching at the last minute. (Yeah, lots of systems will be 64-bit by then, but there will still be a lot of embedded crackerbox systems running 32-bit timestamps. It's all the embedded stuff I'm worried about).

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 ago
  http://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 ago
    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.
btilly 14y ago
If you think that being 64-bit protects you, then you do not understand the problem. The problem is that 32-bit time is embedded in filesystem representations and related protocols. (eg the POSIX specification for file times in tar.) Therefore even if your machine is 64-bit, it still needs to use 32-bit time for many purposes. To name a random example, the POSIX specification for times in the tar format is 32-bit. GNU tar has a non-standard extension that already takes care of it. But will everything else that expects to read/write tar files that a GNU tar program implement the same non-standard extension to the format in the same non-standard way? Almost certainly not. And there will be no sign of disaster until the second that we need to start relying on that more precise representation.

by kabdib 14y ago

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 ago
http://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 ago
  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.

btilly 14y ago

If you think that being 64-bit protects you, then you do not understand the problem. The problem is that 32-bit time is embedded in filesystem representations and related protocols. (eg the POSIX specification for file times in tar.) Therefore even if your machine is 64-bit, it still needs to use 32-bit time for many purposes. To name a random example, the POSIX specification for times in the tar format is 32-bit. GNU tar has a non-standard extension that already takes care of it. But will everything else that expects to read/write tar files that a GNU tar program implement the same non-standard extension to the format in the same non-standard way? Almost certainly not. And there will be no sign of disaster until the second that we need to start relying on that more precise representation.