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. Credit: cbaquiran 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. Related content how-to How to examine files on Linux Linux provides very useful options for viewing file attributes, such as owners and permissions, as well as file content. By Sandra Henry Stocker Oct 24, 2024 6 mins Linux how-to 8 easy ways to reuse commands on Linux Typing the same command again and again can become tiresome. Here are a number of ways you can make repeating commands – or repeating commands but with some changes – a lot easier than you might expect. By Sandra Henry-Stocker Oct 15, 2024 5 mins Linux news SUSE Edge upgrade targets Kubernetes and Linux at the edge SUSE Edge 3.1 includes a new stack validation framework and an image builder tool that are aimed at improving the scalability and manageability of complex Kubernetes and Linux edge-computing deployments. By Sean Michael Kerner Oct 15, 2024 6 mins Edge Computing Linux Network Management Software how-to Lesser-known xargs command is a versatile time saver Boost your Linux command line options and simplify your work with xargs, a handy tool for a number of data manipulation tasks. By Sandra Henry Stocker Oct 11, 2024 6 mins Linux PODCASTS VIDEOS RESOURCES EVENTS NEWSLETTERS Newsletter Promo Module Test Description for newsletter promo module. Please enter a valid email address Subscribe