January 1, 1970 => January 19, 2038 Error!
Tags: webdev, learning, codenewbie, web3
Published: 2024-02-24 02:24:42

There have always been key moments in history … important dates … memorable days. Hopefully, we will reach 2038, a historic moment.

Have you noticed that when setting a date, whether with Javascript or another language, the initial date is always January 1, 1970?

Well, I'll explain it to you. This is because it is Unix time. But first, let's talk a little about what UNIX is.

In the late 1960s, MIT, AT&T, and General Electric were working to create an experimental operating system called Multics, which was to run on a mainframe computer. However, the first versions had poor performance.

Later, Ken Thompson of Bell Labs programmed a 'Space Travel' game but discovered that the game was slow and expensive on a General Electric machine. Thompson rewrote the program with the help of Dennis Ritchie on a DEC PDP-7 model computer.

Consequence: Start a new operating system.

Later, Russ Canaday joined, among other programmers. They developed a command interpreter and a small set of programs. Later, they achieved text processing, among other things, and with it … financing and success! In 1972, it was decided to write UNIX again, but in the C language, so that it could be modified to work on other computers.

Thanks gammers and great programmers!

The date they decided to use as a base was January 1, 1970.

Briefly, UNIX is a portable, multitasking, multiuser operating system.

By the way, in 1991, a Helsinki student named Linus Torvalds developed a kernel for computers that emulated many of the functionalities of UNIX and released it as open source under the name LINUX.

Anyway, returning to the starting point, Since January 1, 1970, seconds have been counted, and on most 32-bit systems, the `time_t` data type used to store the seconds counter is a 32-bit signed integer (positive and negative). This means that the last second representable in this format will be at 03:14:07 UTC on January 19, 2038, when the counter reaches 2,147,483,647. One second later, the counter will overflow and jump to the value of -2,147,483,648.

It may not seem important, but this bug can cause quite a few crashes because many programs and devices have an internal clock, so … anything can fail.

Would it be very irresponsible to know this and do nothing?

YEAH

Changing the definition of `time_t` to use a 64-bit type would break binary support for software, data storage, and generally anything that has anything to do with the binary representation of time. Changing `time_t` to an unsigned 32-bit integer would affect programs that do calculations with time differences. 

Most operating systems for 64-bit architectures use 64-bit integers for `time_t`. The migration is still in process but will surely be completed before 2038. Using a 64-bit integer would push the problem back about 290 billion years (2.9 × 1011). That is, 22 times the approximate age of the universe. 

But if you are one of the people who treasures an older device with an internal clock, then you will remember that historical date … or if you were born on January 1, 1970.

By the way, for those curious people, here is a link that shows you the current seconds.[HERE](https://www.unixtimestamp.com/en/index.php)