Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is my second question relating to DateTime. We test our application for all known possibilities of bugs. I came across this issue a year back and after a lot of research I posted an article on CodeProject on this topic. This article will explain the what year 2038 bug is and how it can many of our applications tomorrow. Explaining full details of year 2038 bug was beyond the scope of this question so I've referred to an article which has been written by myself only.

Link text:

What are the applications (server apps, client apps, infrastructure solutions s/w & h/w) which we are using currently that are vulnerable to this bug ?

What are the solutions for the year 2038 bug? How is it possible to upgrade our solutions and applications to deal against the problem?

This question is very futuristic but it's worth the discussion.

share|improve this question

I expect small embedded systems to be most at risk. These are the small systems that runs our elevators, gps receivers, car computer etc. A lot of these devices will still be operating in 2038 with no way to "go online" to check for firmware updates.

share|improve this answer

The short answer is almost any 32-bit OS using unix timestamps.

Some 32-bit versions were fixed to use 64-bit time, however that's always only an option.

Similarly some 64-bit OS' still use a 32-bit time_t and so are still open to wraparound.

In the 30 years still to come before the problem hits I think speculating is not sensible. Make sure anything new uses 64-bit timestamps, and by 2038 there will be very little still around using 32-bit timestamps.

share|improve this answer

I have a feeling, that we are much worse off than we might think:

By 2038, time_t will of course be 64 bit wide on the majority of the systems (just remember where we were 30 years ago), so that one doesn't really matter.

What I perceive to be much more of the problem is many protocols out there that specify 32 bit timestamps as part of their inner workings. NTP, SSL - choose your pick.

Even when the world has moved on and everyone is using 64bit machines, these protocols are sure to be still in use (SMTP was introduced ~30 years ago and still is in wide use, whereas hardware introduced back then isn't really - just to make a point here).

share|improve this answer
Yes, I've discussed this on my article and proposed as one of the solution. – s_ruchit May 27 '09 at 10:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.