2

Possible Duplicate:
What should we do to prepare for 2038?

What is year 2038 problem?

How to find out if our code has that problem and solve it?

Community
  • 1
  • 1
Jay
  • 24,173
  • 25
  • 93
  • 141
  • Numerous duplicates on SO already, e.g. [What should we do to prepare for 2038?](http://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038) and [is anybody doing anything about 2038 time_t bug?](http://stackoverflow.com/questions/3918948/is-anybody-doing-anything-about-2038-time-t-bug) – Paul R Jun 20 '11 at 09:47
  • http://en.wikipedia.org/wiki/Year_2038_problem – Isaac Fife Jun 20 '11 at 09:05

3 Answers3

2

In C the standard 4-byte format assumes that the beginning of time is January 1, 1970, at 12:00:00 a.m. This value is 0.The maximum value of time before it rolls over to a negative (and invalid) value is 2,147,483,647, which translates into January 19, 2038. On this date, any C programs that use the standard time library will start to have problems with date calculations.To correct it simply recompile the programs with a new version of the library that uses 8-byte values for the storage format.

Balanivash
  • 6,709
  • 9
  • 32
  • 48
  • with the 8 bytes, when is the next problem going to show up? – stijn Jun 20 '11 at 09:23
  • nevermind, got it: http://www.merlyn.demon.co.uk/critdate.htm Very interesting read. Seems 2100 will be the next big one after 2038. – stijn Jun 20 '11 at 09:25
  • I dont think we'd be in the foreseeable future, with 4 bytes(e9), it has lasted for 68 yrs, and now with 8 bytes, the number of seconds storable goes to e17. In a yr we have approx e7 seconds, so i think we are good for at least e9 yrs :) – Balanivash Jun 20 '11 at 09:38
  • I dont think we need to worry, we have a lot of time to sort these things out!!! – Balanivash Jun 20 '11 at 09:40
2

Try this: if the second (and third) line are not in 2038, your system has the Year 2038 problem.

#include <stdio.h>
#include <time.h>

int main(void) {
  time_t x;

  x = (time_t)((1U << 31) - 1);
  printf("%s\n", ctime(&x));
  x += 1;
  printf("%s\n", ctime(&x));
  x += 1;
  printf("%s\n", ctime(&x));

  return 0;
}

Code "running" at ideone: problematic system
Code "running" at codepad: problematic system

pmg
  • 106,608
  • 13
  • 126
  • 198
0

The programs that store or use system time in form of unsigned integers since 00:00:00 UTF will run out of range on Jan 19 2038. Although most softwares will face this problem in 2038, the ones that store future dates will get affected earlier.

The workaround will need a recompilation of (related) code that stores time in a larger storage format. Seemingly all the compiler providers are already ready with the solution.

Also, the 64 bit Operating systems are already using 64 bit wrappers for all time integers. This will put the danger well beyond our timeframe. Let the far next generations figure better solutions.

mihsathe
  • 8,904
  • 12
  • 38
  • 54