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.

3 Answers
3

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.

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.

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