Christopher B. Browne's Home Page

4. The 2038 Problem

Linux and other Unix-like OSes that use 32 bit values to represent the number of seconds since 1970 will, on its present course, encounter a "Year 2000-like" problem in early 2038, when, approximately two billion seconds after 1970, timet counters roll around.

The following article describes a preliminary analysis that has been done...

    From: (Bear Giles)
    Newsgroups: comp.os.linux.development.system
    Subject: Y2038: Problems exist; fix by kernel 3.0.x?
    Organization: Dimensional Communications
    Lines: 142
    Message-ID: <6r374h$>
    Date: Sat, 15 Aug 1998 05:42:51 GMT
    NNTP-Posting-Date: Fri, 14 Aug 1998 23:42:51 MDT
    Xref: comp.os.linux.development.system:55396

Some people (including many who should know better) have been claiming that Y2038 "isn't a problem" since it's trivial to change the definition of timet to a 64-bit entity and recompile everything.

Sorry, but that's a load of bovine byproduct.

Here are a list of Y2038 problems in the Linux kernel today in the 2.0.35 and 2.1.115 kernels:

This is far from an exhaustive list; I've identified these problems in just a few hours of free time.

Clearly, Linux (i386) is not Y2038 ready. However I think it's reasonable that a requirement for kernel 3.0 is Y2038 compliance defined as:

If we go straight from 2.2 to 3.0, the Linux community has 2-3 years to make these changes. Piece-o-cake, since many of us will be running 64-bit i386 systems by then. :-)

If we go from 2.2 to 2.4 and thence to 3.0, we have around 5 years for these changes. It's almost harder to justify not making these changes than making them, over such a long time frame.

Finally, there's something to be said for having some rich symbolism in the criteria for 3.0. I suspect that many people will be very pissed off at properietary software in mid-2000, and the Open Software community demonstrating awareness and action to avoid a problem a generation away will be a shocking display of... dare I say it... maturity.


As an aside, many file systems distinuish between a file creation date and a logical creation date. The US Declaration of Independence, for instance, has a LCD of 1776-07-04. Some documents have LCDs with negative years. Fortunately JDN (modified so the day number doesn't change at local noon) is apparently sufficient to ensure that the numbers will never be negative, while the computational costs to convert to/from timet are modest.]


If this was useful, let others know by an Affero rating

Contact me at