Unix time (also known as epoch Time) is the number of seconds that have passed since January 1, 1970. As Unix approaches its 50th birthday, let’s take a look at what worries kernel developers.

2020 is a big year for Unix. Earlier this year, Unix turned 50.

Although some of the early development of Unix predated the official start of its era, January 1, 1970 is still the zero point of POSIX time and the accepted beginning of Unix. January 1, 2020 will mark its 50th anniversary. (LCTT) In fact, the first edition of the Unix Programmer’s Manual, published on November 3, 1971, referred to 1971/1/1 as the beginning of the Unix era and recorded 60 digits a second, but it turned out that such 32-bit integers only lasted more than two years. The era has since been redefined. Changed to 1 number per second starting from 1970/1.)

Unix time and human time

In terms of human time, 50 years is important. Fifty years is nothing special in terms of Unix time. 48.7 years is equally important.

Unix (including Linux) systems store date/time values as the number of seconds (32-bit integer) that have passed since 1970-01-01 00:00:00 UTC. To determine how many seconds have passed since that time and see what Unix time values look like, you can issue the following command:

$ date +%s
1576883876
Copy the code

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

How much time can a Unix system manage?

To see how much time a Unix system can hold, we need to look at the capacity of 32-bit fields. It can be calculated as follows:

$ echo '2 ^ 32' | bc
4294967296
Copy the code

However, because Unix needs to accommodate negative numbers, it reserves one bit for the symbol of the number, reducing it to:

$ echo '2 ^ 31' | bc
2147483648
Copy the code

And, since the Unix count starts with 0, that means we have 2,147,483,648 values, but the maximum possible value is 2,147,483,647. Unix date/time values cannot exceed this number — just as the odometer on a car may not exceed 999,999 miles. Add one and it becomes -2147483648. [LCTT] [LCTT] After reaching the maximum value, 2038/1/19 03:14:07, the next 1 second causes the sign bit to be 1 and the remaining 31 bits to be 0, i.e. -2147483648, and the time to be 1901/12/13 20:45:52. This is the Y2K38 problem.)

How many seconds are there in a year?

The number of seconds in most years can be calculated by multiplying the number of hours per day times the number of minutes per hour times the number of seconds per minute times the number of days in the year:

$ expr 24 \* 60 \* 60 \* 365
31536000
Copy the code

In leap years, we add another day:

$ expr 24 \* 60 \* 60 \* 366
31622400
Copy the code

(LCTT specifies exactly 24 * 60 * 60 = 86400 seconds, ignoring leap seconds.)

How will Unix celebrate its 50th birthday?

12:00 noon on January 1, 2020 is epoch time 1577836800. This calculation is tricky, but mainly because we have to get used to leap years. Since the epoch began, we’ve had 12 leap years, starting in 1972 and ending with 2016. And, when we get to 2020, we’ll have 38 regular years.

Here is the calculation using the expr command to calculate the number of seconds for the 50 years:

$ expr 24 \* 60 \* 60 \* 365 \* 38 + 24 \* 60 \* 60 \* 366 \* 12
1577836800
Copy the code

The first half counts the number of seconds in 38 non-leap years. Then, we add a similar calculation of 366 days in leap years. Alternatively, you can use the number of seconds per year described earlier and do the following:

$ expr 31536000 \* 38 + 31622400 \* 12
1577836800
Copy the code

This way of tracking dates and times made Unix systems completely immune to the Y2K scare, which began in late 1999 with fears that the year 2000 would wreak havoc on computer systems, but there were far fewer problems than feared. In fact, only applications that store years in two-digit format will change the year to 00 to indicate a time lapse. Still, many application developers do a lot of extra tedious work to make sure their systems don’t have serious problems by the time 2000 rolls around.

When do YOU encounter problems with Unix time?

Unix systems will not experience Y2K type problems until 2038, when the storage dates described above will exceed their 32-bit space allocation. But that’s only 18 years from now, and kernel developers are already figuring out how to avert disaster. But it is too early to start panicking.

The 2038 problem is sometimes called the Y2K38 problem. We have until Tuesday, January 19, 2038 to solve this problem. If the problem is not resolved by then, systems after that date may assume 1901. One way around this problem is to switch to a 64-bit representation of date/time information. Even then, some argue, there are more complicated issues than they sound. In any case, it is too early to panic. And, in the meantime, maybe after singing “Auld Lang Syne” on New Year’s Eve, you can sing “Happy Birthday” to Unix. Unix turns 50, and that’s still a big deal.

(I recommend reading the Unix Time Wikipedia page for more interesting and under-the-radar information.)

Via: www.networkworld.com/article/351…

Author: Sandra Henry-Stocker (lujun9972

This article is originally compiled by LCTT and released in Linux China