Your new tech is still stuck in the year 1970 — here's why

There's a good chance you've seen the date January 1, 1970 on a computer or other device, even if you weren't alive back then. You might assume this represents a significant date in computing, or that it's a random placeholder date for when a machine fails to read the time. In actuality, while the date is not special in itself, it represents an important part of how computers keep time.

Like everything in computing, the method that leads to this date is finite, meaning we'll have problems with it in the future. This all ties into a more interesting discussion of how computers (and humans) keep track of time, which is more complicated than you might think.

January 1, 1970 at 00:00 (midnight) UTC is the epoch of Unix time. An epoch refers to a specific, impactful moment, usually corresponding to the start of a timekeeping system. Unix was one of the first operating systems we would consider modern, beginning development in the late 1960s. It's the basis for many other operating systems that are known as "Unix-like," including Linux, macOS and Android. Windows is the main outlier.

When Unix was in development, its developers needed a way to keep track of time. A few early attempts used the system clock speed of 60Hz, but storing this in a 32-bit integer resulted in a value that would run out of room after less than 2.5 years. After some time, they changed the time-keeping to use seconds and chose January 1, 1970 as a "round" arbitrary date to begin at, figuring that the 32-bit integer for time wouldn't run out of space anytime soon (more on that later).

To this day, Unix time is kept by tracking the number of seconds that have passed since Jan 1, 1970 at midnight UTC. UTC (Coordinated Universal Time) was an obvious choice since it's already the standard for keeping track of time across time zones. It's simple for a computer to compare two numbers and calculate the difference between them without worrying about all the rules we have around time. The system converts the timestamp, including your time zone's offset from UTC, into our human-readable format.

You might see the 1970-01-01 date appear in spreadsheets, apps, file metadata, error screens and various other places. Unless this date happens to line up with someone's birthday or another major event, it's usually the result of an error. When a Unix-like system tries to check the time and runs into a problem or receives a 0 value, it will default to the epoch. If you live in a time zone that's behind UTC, you'll likely see these default values as late in the day on December 31, 1969 instead.

Traditional Unix time is kept as a signed 32-bit integer, a binary value with 32 digits that can each be 1 or 0. Signed integers can track positive and negative numbers, while unsigned integers can only be positive. In the case of tracking time, using a signed value is necessary to track dates before 1970. Because the first (leftmost) bit of a signed integer is used to indicate whether it's negative, it cuts the range of possible values in half compared to an unsigned number.

An unsigned integer's maximum value is 2^31, or 4,294,967,295. A signed value can represent half of this in each direction, going as high as 2,147,483,647 and as low as -2,147,483,648. Unix time thus has an "expiration date." Once that upper limit of seconds has passed, the leftmost digit will become a 1, which causes the rest of the number to be interpreted as negative. This will happen on January 19, 2038 at 3:14:07 AM UTC, which is why you'll hear this called the "year 2038 problem." Once the integer overflows, the time will incorrectly show December 13, 1901 at 8:45:52 PM UTC and continue counting up from there.

Thankfully, we've had (and still have) plenty of time to implement workarounds before this date. Most modern Unix-like systems now use a 64-bit integer to keep track of time, which can keep track of seconds for some 292 billion years before overflowing — if anyone is still around by then, moving time to a 128-bit integer will be their problem. Your modern MacBook is 64-bit and will work fine, while a 32-bit device like an iPhone 4 will run into trouble.

The main risk for when 2038 rolls around is in old systems that can't easily be updated, like those embedded in appliances, vehicles, cameras and similar. Some of those won't be heavily affected even if they can't keep the exact time, but we'll have to replace any of those devices still around in 12 years if time is a critical factor.

You might wonder if this time problem is related to Y2K (which also had a similar name, "year 2000 problem"), which was a big worry going into the new millennium. While both revolve around computers keeping time, the past problem was caused by decimal shorthand, not binary overflow.

In the early days of computing, memory was extremely expensive, so programmers saved wherever possible. It was thus common to use two digits to indicate the year, assuming that the first two digits were always "19". Y2K was the worry that once the year hit 2000, computers would interpret "00" as 1900 (or another earlier date) instead of 2000, causing all kinds of problems for programs that relied on accurate time. It was a big scare at the time, but ended up not being nearly as terrible as expected (which, depending on who you ask, was either due to prevention efforts or because the issue was never huge to begin with).

Other time-tracking methods

Unix time is not the only way that computers handle the clock. Many machines have a real-time clock, which keeps track of the time similarly to a wall clock and retains power using the CMOS battery when the computer is powered off. When this battery dies, your computer's clock won't be right.

Windows, as the exception mentioned earlier, keeps track of time differences in 100-nanosecond ticks starting January 1, 1601 at midnight UTC. While it's much older than 1970, this epoch isn't random; the Gregorian calendar we use goes through a complete cycle every 400 years, so 1601 was the start of the most recent cycle at the time of Windows' development. It's an unsigned 64-bit integer value (as it's unlikely a computer would need to represent dates before 1601) that will become invalid on September 14, 30,828.

Finally, there's NTP (Network Time Protocol), which syncs your computer's time to extremely accurate time-keeping servers over the internet. If the computer's method of keeping the time ever fails or drifts, it receives corrections using NTP. There's a lot more to keeping track of time, like soon-to-be-retired leap seconds, daylight saving time, time zone changes, and calendar shifts, but now you understand more about what computers do to keep track of it.