Site icon LOGMOD

What is Unix Epoch and how does Unix Time work?

Mikhail Leonov / Shutterstock

Unix stores time as the number of seconds since January 1, 1970. And that means Linux does too. We explain this seemingly strange system and why doomsday was scheduled for 2038.

The early days of Unix

Goethe ( 1749-1832 ) stated that “Every second has an infinite value.” That’s true, each of us only has a few seconds here on planet Earth, and we don’t know when our last second will be. But we know our birthday and when our deadly countdown began.

Unix, as the british queen, got two birthdays. Or, more exactly, there have been two different occasions when he began to count the seconds of his existence. The first time Unix started counting from midnight on January 1, 1971.

We can see this quite clearly by reviewing a section from the first edition of the Unix Programmer’s Manual , dated November 3, 1971. Scroll down to page 13 of that section and you will see a description of the timecommand (now gone) . We are told that » timereturns the time since 00:00:00 on January 1, 1971, measured in sixty of a second. “

Calendars and time frames measure time from some significant point in the past, such as a cosmological event, the founding of an empire, or the success of a revolution. In operating systems, an arbitrary date and time are chosen as the point from which the count begins. This is the epoch of that operating system.

Unix used a 32-bit unsigned integer to hold the 60-second count from the epoch. This is a numeric variable capable of containing values ​​in the range 0 to 4,294,967,295 (2 32 −1). That sounds like a lot. But the counter was incremented to 60 times per second and, as the Programmer’s Manual notes, “The chronologically minded user will notice that 2 ** 32 sixties of a second is only about 2.5 years.”

With a consumption rate of 60 numbers per second, the counter would have reached its maximum value on April 8, 1973, just under 829 days later.

The second epoch of Unix

Needless to say, it was acted on quickly. The unsigned integer was replaced with a 32-bit signed whole. It may seem like a surprising choice because a signed integer can contain fewer positive values ​​(2,147,483,647 (2 31 )) than an unsigned integer. However, the consumption speed was also reduced from 60 seconds to full seconds.

It takes more time to count from 0 to 2,147,483,647 counting a number per second than it does to count from 0 to 4,294,967,295 at 60 counts per second. And by quite a margin. The new scheme would not reach its peak value for just over 68 years. This seemed so far in the future that the epoch was even reset to an earlier point in time. The new epoch was set for midnight on January 1, 1970, UTC.

That point, 68 years in the future, is now eerily close. To be precise, we will reach it at 03:14:07 UTC on January 19, 2038.

A simple but effective scheme

Using a single integer to count the number of time steps from a given point in time is an efficient way to store time. No need to store complicated structures for years, months, days and hours. and it is independent of the country, the locality and the time zone.

Multiplying the number in the integer by the size of the time step (in this case, one second) gives you the time since the epoch, and converting from that to location-specific formats with time zone settings is relatively trivial.

However, it does give you a built-in upper limit. Sooner or later it will reach the maximum value it can hold in the chosen variable type. At the time of writing this article, there is only 17 years to go to the year 2038.

It is similar to but slightly different from the problem of the first computer systems of the last century that used two digits to store years. When the calendar was moved to the new year and the new century of 2000, would the value of a year stored as “00” be interpreted as 2000 or 1900?

It is estimated that correct the call » millennium bug »It has cost the United States alone more than $ 100 billion, and it has taken thousands of man-years to fix it globally. There were some problems in the first days of January 2000, but nothing like the disasters that would have taken place if the error had been ignored.

Doomsday is postponed

Because Linux and all Unix-like operating systems share the same problem, the year 2038 issue has been taken seriously for some time, and fixes have been added to the kernel since 2014. This is ongoing and have been added corrections to the kernel as recently as January. .2020 to address the 32-bit integer problem.

Of course, a working Linux computer contains much more than just a kernel. All operating utilities and user-area applications that use system time through the various APIs and interfaces must be modified to expect 64-bit values. File systems too must be updated to accept 64-bit timestamps for files and directories.

Linux is everywhere . A catastrophic failure in Linux would spell failures in all kinds of computer-based systems. Linux runs most of the web, most of the public cloud, and even spaceships. Drive smart homes and autonomous cars. Smartphones have a Unix-derived kernel at their heart. Virtually anything, like network firewalls, routers, and broadband modems, that has operating systems built into it will run on Linux.

It’s great that Linux is on the way to being fixed. We will install the updates and that will be it. But what are the chances that all those devices will be patched and updated? Many of them won’t even be in service by then so that will be a moot point, but some will still be going offline. Hiding in dark, dusty corners in server rooms and rack cabinets perhaps, but they’ll be there, working silently, as the seconds tick by until a quarter past three in the morning on January 19, 2038.

But devices like that should be a small minority. The vast majority of systems will see the time of crisis come and go without incident. Once again, we can relax. At least, until the year 2486 approaches, bringing with it the exact same problem for systems that use 64-bit-based integers to count time from epoch.

The date command

We can use the datecommand to verify Linux and other Unix derivatives that still use the original and simple scheme of storing the time value as the number of seconds since the epoch.

The use of datecommand without any parameters prints current date and time in terminal window. The time zone for which the time is set is also shown. EDT is Eastern Daylight Time, which means that our test computer is in the Eastern time zone and the summer schedule is in force. When daylight saving time is not in effect, the Eastern Time Zone uses Eastern Standard Time.

To see the underlying integer value, we can use a display format string. Format strings have a plus sign “+” as the first character. The format token “% s” means “show seconds since epoch”.

If we take the value of seconds returned by dateand we feed it back in the datecommand with the -doption (show the time described by a string), will convert it back to a normal date and time.

fecha +% s
fecha -d  @ 1633183955

We can show that the integer value actually represents time by showing the number of seconds, sleeping for 10 seconds, and showing the new number of seconds. The two integer values ​​will be exactly 10 different.

fecha +% s && dormir 10 && fecha +% s

We have seen that we can spend a few seconds datecommand and it becomes a date and time for us. If we do that using zero seconds as input to our value, datewe should print the date and time from the Unix era.

TZ = fecha 'UTC' -d  @ 0  + '% x% R'

The command breaks down like this:

  • TZ = ‘UTC’ : The time was established using the Coordinated Universal Time (UTC, so we must tell you datethat uses UTC. The “TZ =” construct sets the effective time zone for the current command only.
  • date : The datecommand.
  • -d @ 0 : We tell datethat uses a string as input, not the time “right now”. The string we pass has zero seconds.
  • + ‘% x% R’ : the output format string. The format token “% x” indicates datethe year, month and day are displayed. The format token “% R” indicates that dateyou must use the 24-hour format for hours and minutes. Because there are spaces in the format string, we wrap the entire string in single quotes ” '”So that the string is treated as a single element.

As expected, the departure is midnight on January 1, 1970.

Until next time

Simple is usually best. Counting the seconds from a fixed data is the easiest way to mark the passage of time. But the passage of time brings new challenges. With the fixes that have been implemented, it seems that we are clear until the year 2486.

I think it’s safe to say that we’ll worry about that a little bit closer to the moment.

Exit mobile version