Year 2038 problem

Question

What is the likelihood of the Year 2038 issue being very problematic?

Answer 1

I have encountered this problem in an embedded Linux system that needed to handle dates past 2038 in some long-term cryptographic certificates, so I'd say the likehood of this depends on your application domain.

While most systems should be ready well before 2038, if you find yourself today calculating dates far into the future, you may have a problem.

Answer 2

I think this is going to be a significant problem, much more pernicious than the Y2K issues of 1999/2000 because the affected code is generally lower-level (it's CTIME) and so it's harder to spot places where time is being stored that way.

To complicate matters further, the fact that Y2K was perceived to be a damp squib will make it harder to draw attention to the problem in the runup to the event.

Cultural references:

Cory Doctorow was trying out a new model for short story commisioning / publishing under open licenses, and I suggested a 2038 theme o one of them, which he did brilliantly in Epoch: http://craphound.com/?p=2337

Answer 3

This is my opinion, but this problem is due to a 32 bit counter problem, today most os are updated to handle time on 64 bit (at least on 64 bit computers), so I guess that all OS and software will be ready a long time before 2038, let's say 2010. So you might only have problems if in 2038 you will still be running software from 2020.
It likely not be a problem in almost all case. I hope.

Answer 4

A 64 bit OS is ultimately irrelevant to the 2037 problem. (CTIME runs out closer to 2037 than 2038).

The question is not the bit depth of the OS, rather how does the OS store time. Or how does the database column choose to store time. Or how does this directory services time syntax attribute store time at the back end.

This is a much bigger problem than people think, since it is so endemic and common to have used 32 bit time counters.

Each instance that stores time needs to be revisited, and all API's updated, and all tools that use it updated as well.

Abstraction layers that let you set time via a human readable time format, instead of the raw data written out make it easier, but that is only one case.

I suspect this is going to be a much bigger deal than most people think.

Answer 5

A few years ago, there were reports of problems already, in areas like mortgage programs doing calculations on 30-year loans: 2008 + 30 = 2038.

Answer 6

Not such a big deal.

During the first Y2K blitz, in which software and hardware vendors were required to certify their products as "Y2K compliant" in order to be sold (I remember network cables on PC Connection being certified Y2K compliant) a lot of companies did detailed audits of everything, by setting clocks in the future and testing.

At the time, since the cost of testing was so high, they almost always tested with several dates, such as 1/1/99 (some developers may have used 99 as a sentinal), 12/31/99, 1/1/00, the leapness of 2000, 1/19/38, and many others. See here for a tedious list.

Thus I believe that any important software that was around in 1999 will probably not have 2038 bugs, but new software written since then by ignorant programmers might. After the whole Y2K debacle programmers generally became much more aware of date encoding issues so it's unlikely to be as big an impact as Y2K was (which, in itself, was something of an anticlimax).

Answer 7

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

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

it should be 1 instead of 9 but ctime does not handle larger date:

8 - Sun Jun 13 07:26:08 1141709097

My system (64 bit of course) time can run even 1 million years more. The solution is to update the systems to 64 bits.

The catch is that the programs may not handle it. Especially old, propertary and not maintained. Devs are used to following facts:

• int's are 32 bits (in fact they are preserved as 32 bits on 64-bit systems among others because it was assumed they are 32 bit always)
• Most types (such as time_t) can safely be casted on int

In popular FLOSS software both things will probably not get through the 'many eyes' review. On less popular and propertary it will largly depend on author.

I guess on free *nix world the 2038 will get 'unnoticed' while I do expect problems on "propertary" platforms (i.e. those with large number of propertary software) - especially if some of the crutial part will not be maintained.

Answer 8

If it's anything like Y2K, some people have already been affected and are changing software, but most developers will ignore it until sometime in the 2030s, probably 2035 or so, at which point there will be a lot of work done, and anybody old enough to know K&R C and not yet too senile will suddenly be able to contract out for a lot of money. The actual transition will show a lot of things not yet done, probably none all that important.

Answer 9

The Y2K problem was two charters representing the year instead of four.

Many system had no way to distinguish between 2000 from 1900 since they only stored the '00'.

Almost all system either now use 4 chars to store the year, or they use a library of some sort.

So lets all worry about the year 10000 (Y10K) instead. Except for the OS and Library writers...