ResponTodo

Unix almacena el tiempo como el número de segundos desde el 1 de enero de 1970. Y eso significa que Linux también lo hace. Explicamos este sistema aparentemente extraño y por qué el día del juicio final estaba programado para 2038.

La primera época de Unix

Goethe ( 1749-1832 ) declaró que «Cada segundo tiene un valor infinito». Eso es cierto, cada uno de nosotros solo tiene unos segundos aquí en el planeta Tierra, y no sabemos cuándo será nuestro último segundo. Pero sabemos nuestro cumpleaños y cuándo comenzó nuestra cuenta regresiva mortal.

Unix, como la  reina británica, tiene dos cumpleaños. O, más exactamente, ha habido dos ocasiones distintas en las que empezó a contar los segundos de su existencia. La primera vez que Unix comenzó a contar desde la medianoche del 1 de enero de 1971.

Podemos ver esto con bastante claridad al revisar una sección de la primera edición del  Manual del programador de Unix , con fecha del 3 de noviembre de 1971. Desplácese hacia abajo hasta la página 13 de esa sección y verá una descripción del timecomando (ahora desaparecido) . Se nos dice que » timedevuelve el tiempo desde las 00:00:00 del 1 de enero de 1971, medido en sesenta de segundo».

Los calendarios y los sistemas de tiempo miden el tiempo a partir de algún punto significativo del pasado, como un evento cosmológico, la fundación de un imperio o el éxito de una revolución. En los sistemas operativos, se eligen una fecha y una hora arbitrarias como el punto a partir del cual comienza el conteo. Esta es la época de ese sistema operativo.

Unix usó un entero sin signo de 32 bits para contener la cuenta de 60 segundos desde la época. Ésta es una variable numérica capaz de contener valores en el rango de 0 a 4,294,967,295 (2 ³² −1). Eso suena a mucho. Pero el contador se incrementó a 60 veces por segundo y, como señala el Manual del programador, «El usuario con mentalidad cronológica notará que 2 ** 32 sexagésimas de segundo es solo alrededor de 2.5 años».

Con una tasa de consumo de 60 números por segundo, el contador habría alcanzado su valor máximo el 8 de abril de 1973, poco menos de 829 días después.

La segunda época de Unix

No hace falta decir que se actuó rápidamente. El entero sin signo fue reemplazado con un 32-bit firmado entero. Puede parecer una elección sorprendente porque un entero con signo puede contener un número menor de valores positivos (2,147,483,647 (2 ³¹ )) que un entero sin signo. Sin embargo, la velocidad de consumo también se redujo de 60 segundos a segundos completos.

Se necesita más tiempo para contar de 0 a 2,147,483,647 contando un número por segundo que contar de 0 a 4,294,967,295 a 60 cuentas por segundo. Y por bastante margen. El nuevo esquema no alcanzaría su valor máximo durante poco más de 68 años. Esto parecía tan lejano en el futuro que la época incluso se restableció a un punto anterior en el tiempo. La nueva época se fijó para la medianoche del 1 de enero de 1970, UTC.

Ese punto, 68 años en el futuro, está ahora inquietantemente cerca. Para ser precisos, lo alcanzaremos a las 03:14:07 UTC del 19 de enero de 2038.

Un esquema simple pero efectivo

Usar un solo entero para contar el número de pasos de tiempo desde un punto dado en el tiempo es una forma eficiente de almacenar el tiempo. No es necesario almacenar estructuras complicadas de años, meses, días y horas. y es independiente del país, la localidad y la zona horaria.

Multiplicar el número en el entero por el tamaño del paso de tiempo (en este caso, un segundo) le da el tiempo desde la época, y convertir de eso a formatos específicos de la localidad con ajustes de zona horaria es relativamente trivial.

Sin embargo, le da un límite superior incorporado. Tarde o temprano alcanzará el valor máximo que puede mantener en el tipo de variable elegido. En el momento de escribir este artículo, solo faltan 17 años para el año 2038.

Es similar pero ligeramente diferente al problema de los primeros sistemas informáticos del siglo pasado que usaban dos dígitos para almacenar años. Cuando el calendario se trasladó al año nuevo y al nuevo siglo de 2000, ¿el valor de un año almacenado como «00» se interpretaría como 2000 o 1900?

Se estima que corregir el llamado » error del milenio » le ha costado a los Estados Unidos solo más de $ 100 mil millones, y ha llevado miles de años-hombre para solucionarlo a nivel mundial. Hubo algunos problemas en los primeros días de enero de 2000, pero nada como los desastres que habrían tenido lugar si se hubiera ignorado el error.

Se pospone el día del juicio final

Debido a que Linux y todos los sistemas operativos similares a Unix comparten el mismo problema, el problema del año 2038 se ha tomado en serio durante algún tiempo, y se han agregado correcciones al kernel desde 2014. Esto está en curso y se han agregado correcciones  al kernel  tan recientemente como enero. .2020 para abordar el problema de los enteros de 32 bits.

Por supuesto, una computadora Linux en funcionamiento contiene mucho más que un kernel. Todas las utilidades operativas y las aplicaciones de área de usuario que hacen uso del tiempo del sistema a través de las diversas API e interfaces deben modificarse para esperar valores de 64 bits. Los sistemas de archivos también  deben actualizarse  para aceptar marcas de tiempo de 64 bits para archivos y directorios.

Linux está en todas partes . Una falla catastrófica en Linux significaría fallas en todo tipo de sistemas basados ​​en computadora. Linux ejecuta la mayor parte de la web, la mayor parte de la nube pública e incluso naves espaciales. Maneja casas inteligentes y autos autónomos. Los teléfonos inteligentes tienen un núcleo derivado de Unix en su corazón. Prácticamente cualquier cosa, como firewalls de red, enrutadores y módems de banda ancha, que tenga sistemas operativos integrados en su interior se ejecute en Linux.

Es genial que Linux esté en camino de ser reparado. Instalaremos las actualizaciones y eso será todo. Pero, ¿cuáles son las posibilidades de que todos esos dispositivos sean parcheados y actualizados? Muchos de ellos ni siquiera estarán en servicio para entonces, por lo que será un punto discutible, pero algunos aún se estarán desconectando. Escondidos en rincones oscuros y polvorientos en salas de servidores y gabinetes en rack quizás, pero estarán allí, trabajando silenciosamente, mientras los segundos pasan hasta las tres y cuarto de la mañana del 19 de enero de 2038.

Pero dispositivos como ese deberían ser una pequeña minoría. La gran mayoría de los sistemas verán el tiempo de crisis llegar y desaparecer sin incidentes. Una vez más, podremos relajarnos. Al menos, hasta que se acerque el año 2486, trayendo consigo exactamente el mismo problema para los sistemas que usan enteros basados ​​en 64 bits para contar el tiempo desde la época.

El comando de la fecha

Podemos usar el datecomando para verificar Linux y otros derivados de Unix que todavía usan el esquema original y simple de almacenar el valor de tiempo como el número de segundos desde la época.

El uso del datecomando sin ningún parámetro imprime la fecha y hora actuales en la ventana del terminal. También se le muestra la zona horaria para la que se ajusta la hora. EDT es la hora de verano del este, lo que significa que nuestra computadora de prueba se encuentra en la zona horaria del este y el horario de verano está en vigor. Cuando el horario de verano no está en vigor, la zona horaria del este utiliza el horario estándar del este.

Para ver el valor entero subyacente, podemos usar una cadena de formato de visualización. Las cadenas de formato tienen un signo más «+» como primer carácter. El token de formato «% s» significa «mostrar los segundos desde la época».

Si tomamos el valor de segundos devuelto por datey lo retroalimentamos en el datecomando con la -dopción (mostrar el tiempo descrito por una cadena), lo convertirá de nuevo a una fecha y hora normales.

fecha

fecha +% s

fecha -d  @ 1633183955

Podemos mostrar que el valor entero realmente representa el tiempo mostrando el número de segundos, durmiendo durante 10 segundos y mostrando el nuevo número de segundos. Los dos valores enteros serán exactamente 10 diferentes.

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

Hemos visto que podemos pasar unos segundos al datecomando y se convierte en una fecha y hora para nosotros. Si hacemos eso usando cero segundos como entrada de nuestro valor, datedeberíamos imprimir la fecha y hora de la época de Unix.

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

El comando se descompone así:

• TZ = ‘UTC’ : La época se estableció usando la Hora Universal Coordinada (UTC, por lo que debemos indicarle dateque use UTC. La construcción “TZ =” establece la zona horaria efectiva solo para el comando actual.
• fecha : El datecomando.
• -d  @ 0 : Le decimos dateque use una cadena como entrada, no la hora «ahora mismo». La cuerda que pasamos tiene cero segundos.
• + ‘% x% R’ : la cadena de formato de salida. El token de formato «% x» indica dateque se muestre el año, mes y día. El token de formato «% R» indica que se datedebe utilizar el formato de 24 horas para las horas y los minutos. Debido a que hay espacios en la cadena de formato, envolvemos toda la cadena entre comillas simples ” '” para que la cadena se trate como un solo elemento.

Como se esperaba, la salida es la medianoche del 1 de enero de 1970.

Hasta la proxima vez

Lo simple suele ser lo mejor. Contar los segundos a partir de un dato fijo es la forma más sencilla de marcar el paso del tiempo. Pero el paso del tiempo trae nuevos desafíos. Con las correcciones que se han implementado, parece que estamos claros hasta el año 2486.

Creo que es seguro decir que nos preocuparemos por eso un poco más cerca del momento.