Home / Blogs

Y2038: It’s a Threat

Last month, for the 20th anniversary of Y2K, I was asked about my experiences. (Short answer: there really was a serious potential problem, but disaster was averted by a lot of hard work by a lot of unsung programmers.) I joked that, per this T-shirt I got from a friend, the real problem would be on January 19, 2038, and 03:14:08 GMT.

Why might that date be such a problem?

On Unix-derived systems, including Linux and MacOS, time is stored internally as the number of seconds since midnight GMT, January 1, 1970, a time known as “the Epoch.” Back when Unix was created, timestamps were stored in a 32-bit number. Well, like any fixed-size value, only a limited range of numbers can be stored in 32 bits: numbers from -2,147,483,648 to 2,147,483,647. (Without going into technical details, the first of those 32 bits is used to denote a negative number. The asymmetry in range is to allow for zero.)

I immediately got pushback: did I really think that 18 years hence, people would still be using 32-bit systems? Modern computers use 64-bit integers, which can allow for times up to 9,223,372,036,854,775,807 seconds since the Epoch. (What date is that? I didn’t bother to calculate it, but it’s about 292,271,023,045 years, a date that’s well beyond when it is projected that the Sun will run out of fuel. I don’t propose to worry about computer timestamps after that.)

It turns out, though, that just as with Y2K, the problems don’t start when the magic date hits; rather, they start when a computer first encounters dates after the rollover point, and that can be a lot earlier. In fact, I just had such an experience.

A colleague sent me a file from his Windows machine; looking at the contents, I saw this.

$ unzip -l zipfile.zip<br /> Archive: zipfile.zip<br /> Length Date Time Name<br /> ——— ——— ———<br /> 2411339 01-01-2103 00:00 Anatomy…<br /> ——— ———

Look at that date: it’s in the next century! (No, I don’t know how that happened.) But when I looked at it after extracting on my computer, the date was well in the past:

$ ls -l Anatomy…<br /> -rw-r-r-@ 1 smb staff 2411339 Nov 24 1966 Anatomy…


After a quick bit of coding, I found that the on-disk modification time of the extracted file was 4,197,067,200 seconds since the Epoch. That’s larger than the limit! But it’s worse than that. I translated the number to hexadecimal (base 16), which computer programmers use as an easy way to display the binary values that computers use internally. It came to FA2A29C0. (Since base 16 needs six more digits than our customary base 10, we use the letters A–F to represent them.) The first “F”, in binary, is 1111. And the first of those bits is the so-called sign bit, the bit that tells whether or not the number is negative. The value of FA2A29C0, if treated as a signed, 32-bit number, is -97,900,096, or about 3.1 years before the Epoch. Yup, that corresponds exactly to the November 24, 1966 date my system displayed. (Why should +4,197,067,200 come out to -97,900,096? As I indicated, that’s moderately technical, but if you want to learn the gory details, the magic search phrase is “2’s complement”.)

So what happened? MacOS does use 64-bit time values, so there shouldn’t have been a problem. But the “ls” command (and the Finder graphical application) do do some date arithmetic. I suspect that there is old code that is using a 32-bit variable, thus causing the incorrect display.

For fun, I copied the zip file to a Linux system. It got it right, on extraction and display:

$ ls -l Anatomy…<br /> -rw-r—r— 1 smb faculty 2411339 Jan 2 2103 Anatomy…

(Why January 2 instead of January 1? I don’t know for sure; my guess is time zones.)

So: there are clearly some Y2038 bugs in MacOS today. In other words, we already have a problem. And I’m certain that these aren’t the only ones, and that we’ll be seeing more over the next 18 years.

Update: I should have linked to this thread about a more costly Y2038 incident.

By Steven Bellovin, Professor of Computer Science at Columbia University

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC