6

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

I don't mean 'people' in the abstract. I mean are you doing anything and if so what?

I am an ancient programmer and recall when I wrote COBOL in the late 70's saying to others in my team "you know - this isn't going to work in 2000". To which the reply was "yeah but this system wont be in use by then, that's 25 years away".

2038 is 28 years away.

Community
  • 1
  • 1
pm100
  • 48,078
  • 23
  • 82
  • 145
  • 8
    Is 2038 after 2012? Yes? First things first, dude. – Anthony Pegram Oct 12 '10 at 20:57
  • 4
    Please make this a community wiki question. The right answer could be "I'm drinking heavily." Or the right answer could be that it's a minor OS problem. Windows will be gone, and the 64-bit Linux kernel won't have this problem. – S.Lott Oct 12 '10 at 20:58
  • 3
    Possible duplicate of: [What should we do to prepare for 2038?](http://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038) – Joe Stefanelli Oct 12 '10 at 20:59
  • 1
    How about - I'll be pushing daisies ? – Romain Hippeau Oct 12 '10 at 20:59
  • 3
    not doing anything will get you a job in 28 years ;) – Chris Oct 12 '10 at 21:02
  • 1
    @GMan: Anthony was joking. 2012 is the end of the Mayan calendar, and some think this is when they predicted the end of the world to be. – nategoose Oct 12 '10 at 21:06
  • @Anthony @nategoose: Oh, sorry. Been dealing with a lot of *actually* stupid people. – GManNickG Oct 12 '10 at 21:14
  • lol I was wondering what 2012 reference was. Windows doesnt use time_t. 64 bit kernel is only partial fix. I see nobody really cares :-( – pm100 Oct 12 '10 at 21:29
  • "64 bit kernel is only partial fix"? Are you saying **nothing** will change in the kernel in two decades? What are you saying? – S.Lott Oct 12 '10 at 21:34
  • it doesnt fix all the persistent data out there that has 32 bit dates. Doesnt fix code that has 'int time' (a lot). 64 bit fixes a lot , but its not magic – pm100 Oct 12 '10 at 21:46
  • @pm100: "doesn't fix code that has `int time`" - well, for one thing I'm not doing anything to 2028-proof code that I have no control over. Which obviously is a problem when combined with the fact that Chris and Romain are deliberately writing non-2038-proof code, but not one I have any power to do anything about. I'm inclined to suspect the full solution is to data-flow analyse anything that calls a time function (including time parsers), ensure the result doesn't get near any data type other than `time_t`, and sack anyone whose code can't be solved by DFA ;-) – Steve Jessop Oct 13 '10 at 00:18
  • @pm100: alternatively, do exactly the same as we did with 2000. That rollover went pretty well, if anything many shops over-compensated. – Steve Jessop Oct 13 '10 at 00:20
  • I don't think anyone will still be running 32-bit hardware or software 38 years from now. And any 64-bit system automatically has 64-bit `time_t`. – R.. GitHub STOP HELPING ICE Oct 13 '10 at 02:25

5 Answers5

12

I add a disclaimer to the release notes of my software that says: Best before 2038.

PeterK
  • 6,287
  • 5
  • 50
  • 86
5

Praying and getting ready for the next wave of expensive consulting gigs. Just in time for retirement!

kprobst
  • 16,165
  • 5
  • 32
  • 53
2

When I need to store seconds from the epoch, I use a 64-bit type. If I need to store a time stamp and storage isn't tight, I'll use an ISO-8601 formatted string.

Troy J. Farrell
  • 1,252
  • 11
  • 18
2

Many systems use a 64 bit time_t which won't wrap for a very long time (for ticks=seconds).

In my own code I just make sure to use a representation for time that has a very long period, or sometimes when doing embedded stuff I just design things so that wrapping around does not matter by restricting my time calculations to relatively small (compared to the length of measurable time) time deltas.

nategoose
  • 12,054
  • 27
  • 42
1

The easiest way, I think, is to write software that can be easily maintainable. That is, low coupling between data models and algorithms operating over them. Most DBMSs and computer languages are already been designed to support this kind of abstraction.

JPCF
  • 2,232
  • 5
  • 28
  • 50