Americas

  • United States
sandra_henrystocker
Unix Dweeb

Unix is turning 50. What does that mean?

How-To
Dec 24, 20194 mins
Linux

Unix time, also known as 'epoch time,' is the number of seconds that have passed since Jan 1, 1970. As Unix turns 50, let's take a look at what worries kernel developers.

2020 is a significant year for Unix. At the very start of the year, Unix turns 50.

While some of the early development of Unix predates the official start of its “epoch,” Jan 1, 1970 remains the zero-point in POSIX time and the recognized beginning of all things Unix. Jan 1, 2020 will mark 50 years since that moment.

Unix time vs human time

In terms of human time, 50 years is a big deal. In terms of Unix time, there’s nothing particularly special about 50 years. 48.7 years would be no less significant.

Unix (including Linux) systems store date/time values as the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC in 32 bits. To determine how many seconds have passed since that time and, thus, what right now looks like as a Unix time value, you can issue a command like this:

$ date +%s
1576883876

The %s argument tells the date command to display the current date/time as the number of seconds since the start of 1970-01-01.

How much time can Unix systems manage?

To understand how much time Unix systems can accommodate, we need to look at the capacity of a 32-bit field. It can be calculated like this:

$ echo '2^32' | bc
4294967296

However, since Unix needs to accommodate negative numbers, it reserves one bit for a number’s sign, thus reducing this to:

$ echo '2^31' | bc
2147483648

And, since Unix numbering begins with 0, that means we have 2,147,483,648 values, but the largest possible value is 2,147,483,647. Unix date/time values cannot exceed that number – just like the odometer on your car probably can’t exceed 999,999 miles. Add 1 and the value turns to 0.

How long is a year in seconds?

The number of seconds in most years can be calculated like this – hours/day multiplied by minutes/hour multiplied by seconds/minute multiplied by the number of days in a year:

$ expr 24 * 60 * 60 * 365
31536000

In leap years, we just add another day:

$ expr 24 * 60 * 60 * 366
31622400

How will Unix see its 50 year birthday?

12:00 AM on Jan 1, 2020 will be 1577836800 in epoch time. The calculation is a little tricky, but mostly because we have to accommodate leap years. Since the start of the epoch, we’ve had 12 leap years, starting in 1972, the last in 2016. And, when we reach 2020, we will have had 38 regular years.

Here’s a calculation using the expr command to count the seconds in these 50 years:

$ expr 24 * 60 * 60 * 365 * 38 + 24 * 60 * 60 * 366 * 12
1577836800

The first half of that is calculating the seconds in the 38 non-leap years. We then add a similar calculation for leap years with their 366 days. Conversely, you could use the seconds per year figures presented earlier and just do this:

$ expr 31536000 * 38 + 31622400 * 12
1577836800

This way of tracking dates and times made Unix systems fairly impervious to the Y2K scare that had people in late 1999 worried that moving into the year 2000 would wreak havoc on computer systems. Far fewer problems were experienced than people feared. In fact, only applications which stored years in a two-digit format would see the year going to 00 as a sign that time jumping backwards. Still, lots of application developers had some tedious extra work piled onto their plates to ensure that their systems wouldn’t run into serious problems when 2000 hit.

When Unix time will run into problems

Unix systems won’t run into a Y2K type of problem until 2038 when dates stored as described above will overrun their 32-bit space allotments. But that’s 18 years from now, and kernel developers are already working on how they will avert disaster. It’s a bit too early to start panicking.

The year 2038 problem is sometimes referred to as the Y2K38 problem. We have until Tuesday, January 19, 2038 to address it. If the problem isn’t resolved, systems after that date may think it’s 1901. One way to address the problem would be to switch to 64-bit representations of date/time information. Some people believe that even that will be a lot more complex than it sounds. In any case, it’s probably still too early to panic. And, in the meantime, maybe after singing “Auld Lang Syne” this New Year’s Eve, you can sing “Happy Birthday” to Unix. It’s turning 50, and that’s still a very big deal.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.