Tiempo de Unix

Para la función de hora de Wikipedia, o #time, consulte Ayuda: función de hora .

Sistema de identificación de instantes en el tiempo para computadoras

Hora actual de Unix
1615681874 (actualización)
(2021-03-14T00: 31: 14 + 00: 00)

Pasó el tiempo de Unix 1 000 000 000 segundos en 2001-09-09T01: 46: 40Z. Se celebró en Copenhague, Dinamarca, en una fiesta organizada por DKUUG (a las 03:46:40 hora local).

El tiempo Unix (también conocido como Epoch time , POSIX time , ^[1] segundos desde Epoch , ^[2] o UNIX Epoch time ^[3] ) es un sistema para describir un punto en el tiempo . Es el número de segundos que han transcurrido desde la época de Unix , menos los segundos intercalares ; la época Unix es a las 00:00:00 UTC del 1 de enero de 1970 (una fecha arbitraria); los segundos bisiestos se ignoran, ^[4] con un segundo bisiesto que tiene la misma hora Unix que el segundo anterior, y cada día se trata como si contuviera exactamente86 400 segundos. ^[2] Debido a este tratamiento, la hora Unix no es una verdadera representación de UTC.

El tiempo Unix se usa ampliamente en sistemas operativos y formatos de archivo . En sistemas operativos similares a Unix, datees un comando que imprimirá o establecerá la hora actual; de forma predeterminada, imprime o establece la hora en la zona horaria del sistema , pero con la -ubandera, imprime o establece la hora en UTC y, con la TZ variable de entorno configurada para referirse a una zona horaria en particular, imprime o establece la hora en esa zona horaria. ^[5]

Definición

Dos capas de codificación componen el tiempo de Unix. La primera capa codifica un punto en el tiempo como un número real escalar que representa el número de segundos que han pasado desde las 00:00:00 UTC del jueves 1 de enero de 1970. ^[6] La segunda capa codifica ese número como una secuencia de bits o dígitos decimales. 

Como es estándar con UTC, este artículo etiqueta los días usando el calendario gregoriano y cuenta los tiempos dentro de cada día en horas, minutos y segundos. Algunos de los ejemplos también muestran el Tiempo Atómico Internacional (TAI), otro esquema de tiempo que usa los mismos segundos y se muestra en el mismo formato que UTC, pero en el que todos los días son exactamente86 400 segundos de duración, perdiendo gradualmente la sincronización con la rotación de la Tierra a una velocidad de aproximadamente un segundo por año.

Codificar el tiempo como un número

La hora Unix es un número con signo único que aumenta cada segundo, lo que hace que sea más fácil para las computadoras almacenar y manipular que los sistemas de fecha convencionales. Los programas de interpretación pueden convertirlo a un formato legible por humanos.

La época Unix es la hora 00:00:00  UTC del 1 de enero de 1970. ^[2] Hay un problema con esta definición, ya que UTC no existió en su forma actual hasta 1972; este tema se analiza a continuación. En aras de la brevedad, el resto de esta sección utiliza el formato de fecha y hora ISO 8601 , en el que la época de Unix es 1970-01-01T00: 00: 00Z.

El número de tiempo de Unix es cero en la época de Unix y aumenta exactamente 86 400 por día desde la época. Así 2004-09-16T00: 00: 00Z,12 677 días después de la época, está representado por el número de tiempo Unix12 677 ×86 400 =1 095 292 800 . Esto también puede extenderse hacia atrás desde la época, usando números negativos; así 1957-10-04T00: 00: 00Z,4472 días antes de la época, está representado por el número de tiempo de Unix−4472 ×86 400 =−386 380 800 . Esto también se aplica en unos días; el número de tiempo en cualquier momento dado de un día es el número de segundos que han pasado desde la medianoche que comienza ese día sumado al número de tiempo de esa medianoche.

Debido a que el tiempo de Unix se basa en una época, y debido a un malentendido común de que la época de Unix es la única época (a menudo llamada " la época " ^[2] ), el tiempo de Unix a veces se denomina tiempo de época . ^{[7] [8] [9]}

Segundos bisiestos

El esquema anterior significa que en un día UTC normal, que tiene una duración de 86 400 segundos, el número de tiempo de Unix cambia de manera continua a lo largo de la medianoche. Por ejemplo, al final del día utilizado en los ejemplos anteriores, las representaciones de tiempo progresan de la siguiente manera:

Hora Unix desde la medianoche hasta el 17 de septiembre de 2004 (sin segundos intercalares)

TAI (17 de septiembre de 2004)	UTC (16 al 17 de septiembre de 2004)	Tiempo de Unix
2004-09-17T00: 00: 30.75	2004-09-16T23: 59: 58.75	1 095 379 198 0,75
2004-09-17T00: 00: 31.00	2004-09-16T23: 59: 59.00	1 095 379 199 0,00
2004-09-17T00: 00: 31.25	2004-09-16T23: 59: 59.25	1 095 379 199 0,25
2004-09-17T00: 00: 31.50	2004-09-16T23: 59: 59.50	1 095 379 199 0,50
2004-09-17T00: 00: 31.75	2004-09-16T23: 59: 59.75	1 095 379 199 0,75
2004-09-17T00: 00: 32.00	2004-09-17T00: 00: 00.00	1 095 379 200 0,00
2004-09-17T00: 00: 32.25	2004-09-17T00: 00: 00.25	1 095 379 200 0,25
2004-09-17T00: 00: 32.50	2004-09-17T00: 00: 00.50	1 095 379 200 0,50
2004-09-17T00: 00: 32.75	2004-09-17T00: 00: 00.75	1 095 379 200 0,75
2004-09-17T00: 00: 33.00	2004-09-17T00: 00: 01.00	1 095 379 201 0,00
2004-09-17T00: 00: 33.25	2004-09-17T00: 00: 01.25	1 095 379 201 0,25

Cuando ocurre un segundo bisiesto , el día UTC no es exactamente86 400 segundos de duración y el número de tiempo Unix (que siempre aumenta exactamente86 400 cada día) experimenta una discontinuidad . Los segundos intercalares pueden ser positivos o negativos. Nunca se ha declarado ningún segundo intercalar negativo, pero si lo fuera, al final de un día con un segundo intercalar negativo, el número de tiempo Unix aumentaría en 1 hasta el comienzo del día siguiente. Durante un segundo intercalar positivo al final de un día, que ocurre aproximadamente cada año y medio en promedio, el número de tiempo de Unix aumenta continuamente al día siguiente durante el segundo intercalar y luego, al final del segundo intercalar, retrocede en 1 (volviendo al inicio del día siguiente). Por ejemplo, esto es lo que sucedió en sistemas POSIX.1 estrictamente conformes a finales de 1998:

Hora Unix desde la medianoche hasta el 1 de enero de 1999 (segundo intercalar positivo)

TAI (1 de enero de 1999)	UTC (31 de diciembre de 1998 al 1 de enero de 1999)	Tiempo de Unix
1999-01-01T00: 00: 29.75	1998-12-31T23: 59: 58.75	915 148 798 .75
1999-01-01T00: 00: 30.00	1998-12-31T23: 59: 59.00	915 148 799 .00
1999-01-01T00: 00: 30.25	1998-12-31T23: 59: 59.25	915 148 799 0,25
1999-01-01T00: 00: 30.50	1998-12-31T23: 59: 59.50	915 148 799 .50
1999-01-01T00: 00: 30.75	1998-12-31T23: 59: 59.75	915 148 799 .75
1999-01-01T00: 00: 31.00	1998-12-31T23: 59: 60.00	915 148 800 .00
1999-01-01T00: 00: 31.25	1998-12-31T23: 59: 60.25	915 148 800 .25
1999-01-01T00: 00: 31.50	1998-12-31T23: 59: 60.50	915 148 800 .50
1999-01-01T00: 00: 31.75	1998-12-31T23: 59: 60.75	915 148 800 .75
1999-01-01T00: 00: 32.00	1999-01-01T00: 00: 00.00	915 148 800 .00
1999-01-01T00: 00: 32.25	1999-01-01T00: 00: 00.25	915 148 800 .25
1999-01-01T00: 00: 32.50	1999-01-01T00: 00: 00.50	915 148 800 .50
1999-01-01T00: 00: 32.75	1999-01-01T00: 00: 00.75	915 148 800 .75
1999-01-01T00: 00: 33.00	1999-01-01T00: 00: 01.00	915 148 801 0,00
1999-01-01T00: 00: 33.25	1999-01-01T00: 00: 01.25	915 148 801 .25

Los números de tiempo Unix se repiten en el segundo inmediatamente después de un segundo intercalar positivo. El número de tiempo de Unix1 483 142 400 es, por tanto ambiguo: puede referirse tanto al inicio de la segunda salto (31/12/2016 23:59:60) o el final de la misma, un segundo más tarde (01/01/2017 00:00:00 ). En el caso teórico, cuando se produce un segundo intercalar negativo, no se produce ninguna ambigüedad, sino que hay un rango de números de tiempo Unix que no se refieren a ningún punto de la hora UTC en absoluto.

Un reloj Unix a menudo se implementa con un tipo diferente de manejo de segundo intercalar positivo asociado con el Protocolo de tiempo de red (NTP). Esto produce un sistema que no se ajusta al estándar POSIX. Consulte la sección siguiente sobre NTP para obtener más detalles.

Cuando se trata de períodos que no abarcan un segundo intercalar UTC, la diferencia entre dos números de tiempo Unix es igual a la duración en segundos del período entre los puntos correspondientes en el tiempo. Ésta es una técnica computacional común. Sin embargo, cuando ocurren los segundos intercalares, tales cálculos dan una respuesta incorrecta. En aplicaciones donde se requiere este nivel de precisión, es necesario consultar una tabla de segundos intercalares cuando se trata de tiempos Unix, y muchas veces es preferible utilizar una codificación de tiempo diferente que no sufra este problema.

Un número de tiempo Unix se convierte fácilmente en un tiempo UTC tomando el cociente y el módulo del número de tiempo Unix, módulo 86 400 . El cociente es el número de días desde la época y el módulo es el número de segundos desde la medianoche UTC de ese día. Si se le da un número de tiempo Unix que es ambiguo debido a un segundo intercalar positivo, este algoritmo lo interpreta como el tiempo justo después de la medianoche. Nunca genera un tiempo que sea durante un segundo intercalar. Si se le da un número de hora Unix que no es válido debido a un segundo intercalar negativo, genera una hora UTC igualmente inválida. Si estas condiciones son significativas, es necesario consultar una tabla de segundos intercalares para detectarlas.

Variante basada en el protocolo de tiempo de red no síncrono

Comúnmente, un reloj Unix de estilo Mills se implementa con un manejo de segundos intercalares que no es sincrónico con el cambio del número de tiempo Unix. El número de tiempo inicialmente disminuye donde debería haber ocurrido un salto, y luego salta al tiempo correcto 1 segundo después del salto. Esto facilita la implementación y se describe en el artículo de Mills. ^[10] Esto es lo que sucede en un segundo intercalar positivo:

Reloj Unix de estilo Mills no sincrónico
desde la medianoche hasta el 1 de enero de 1999 (segundo intercalar positivo)

TAI (1 de enero de 1999)	UTC (31 de diciembre de 1998 al 1 de enero de 1999)	Expresar	Reloj Unix
1999-01-01T00: 00: 29.75	1998-12-31T23: 59: 58.75	TIME_INS	915 148 798 .75
1999-01-01T00: 00: 30.00	1998-12-31T23: 59: 59.00	TIME_INS	915 148 799 .00
1999-01-01T00: 00: 30.25	1998-12-31T23: 59: 59.25	TIME_INS	915 148 799 0,25
1999-01-01T00: 00: 30.50	1998-12-31T23: 59: 59.50	TIME_INS	915 148 799 .50
1999-01-01T00: 00: 30.75	1998-12-31T23: 59: 59.75	TIME_INS	915 148 799 .75
1999-01-01T00: 00: 31.00	1998-12-31T23: 59: 60.00	TIME_INS	915 148 800 .00
1999-01-01T00: 00: 31.25	1998-12-31T23: 59: 60.25	TIME_OOP	915 148 799 0,25
1999-01-01T00: 00: 31.50	1998-12-31T23: 59: 60.50	TIME_OOP	915 148 799 .50
1999-01-01T00: 00: 31.75	1998-12-31T23: 59: 60.75	TIME_OOP	915 148 799 .75
1999-01-01T00: 00: 32.00	1999-01-01T00: 00: 00.00	TIME_OOP	915 148 800 .00
1999-01-01T00: 00: 32.25	1999-01-01T00: 00: 00.25	TIEMPO DE ESPERA	915 148 800 .25
1999-01-01T00: 00: 32.50	1999-01-01T00: 00: 00.50	TIEMPO DE ESPERA	915 148 800 .50
1999-01-01T00: 00: 32.75	1999-01-01T00: 00: 00.75	TIEMPO DE ESPERA	915 148 800 .75
1999-01-01T00: 00: 33.00	1999-01-01T00: 00: 01.00	TIEMPO DE ESPERA	915 148 801 0,00
1999-01-01T00: 00: 33.25	1999-01-01T00: 00: 01.25	TIEMPO DE ESPERA	915 148 801 .25

Esto se puede decodificar correctamente prestando atención a la variable de estado del segundo salto, que indica sin ambigüedades si el salto se ha realizado todavía. El cambio de la variable de estado es sincrónico con el salto.

Una situación similar surge con un segundo intercalar negativo, donde el segundo que se omite es un poco demasiado tarde. Muy brevemente, el sistema muestra un número de tiempo nominalmente imposible, pero esto puede ser detectado por el estado TIME_DEL y corregido.

En este tipo de sistema, el número de tiempo de Unix viola POSIX en ambos tipos de segundos intercalares. La recopilación de la variable de estado del segundo intercalar junto con el número de tiempo permite una decodificación inequívoca, por lo que se puede generar el número de tiempo POSIX correcto si se desea, o se puede almacenar la hora UTC completa en un formato más adecuado.

La lógica de decodificación necesaria para hacer frente a este estilo de reloj Unix también decodificaría correctamente un reloj hipotético conforme a POSIX utilizando la misma interfaz. Esto se lograría indicando el estado TIME_INS durante la totalidad de un segundo intercalar insertado, luego indicando TIME_WAIT durante la totalidad del segundo siguiente mientras se repite la cuenta de segundos. Esto requiere un manejo sincrónico en segundos intercalares. Esta es probablemente la mejor manera de expresar la hora UTC en forma de reloj Unix, a través de una interfaz Unix, cuando el reloj subyacente no se ve afectado fundamentalmente por los segundos intercalares.

Variante basada en TAI

Se disputa la exactitud fáctica de esta sección . La discusión relevante se puede encontrar en Talk: Unix time . Ayude a garantizar que las declaraciones en disputa se obtengan de manera confiable . ( Abril de 2016 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

Otra variante no conforme, mucho más rara, del mantenimiento del tiempo de Unix implica codificar TAI en lugar de UTC; algunos sistemas Linux están configurados de esta manera. ^[11] Debido a que TAI no tiene segundos intercalares, y cada día TAI dura exactamente 86400 segundos, esta codificación es en realidad una cuenta lineal pura de segundos transcurridos desde 1970-01-01T00: 00: 00  TAI. Esto hace que la aritmética de intervalos de tiempo sea mucho más fácil. Los valores de tiempo de estos sistemas no sufren la ambigüedad que tienen los sistemas POSIX estrictamente conformes o los sistemas controlados por NTP.

En estos sistemas es necesario consultar una tabla de segundos intercalares para convertir correctamente entre UTC y la representación de tiempo pseudo-Unix. Esto se asemeja a la forma en que se deben consultar las tablas de zonas horarias para convertir hacia y desde la hora civil ; la base de datos de la zona horaria de IANA incluye información de segundos intercalares, y el código de muestra disponible de la misma fuente utiliza esa información para convertir entre marcas de tiempo basadas en TAI y la hora local. La conversión también se topa con problemas de definición antes del comienzo en 1972 de la forma actual de UTC (consulte la sección Base UTC a continuación).

Este sistema basado en TAI, a pesar de su parecido superficial, no es tiempo de Unix. Codifica tiempos con valores que difieren en varios segundos de los valores de tiempo POSIX. Una versión de este sistema fue propuesto para su inclusión en la norma ISO C de time.h, pero sólo la parte UTC fue aceptada en 2011. ^[12] A tai_clockhace, sin embargo, existe en C ++ 20.

Representando el número

Un número de tiempo Unix se puede representar en cualquier forma capaz de representar números. En algunas aplicaciones, el número simplemente se representa textualmente como una cadena de dígitos decimales, lo que plantea problemas adicionales triviales. Sin embargo, ciertas representaciones binarias de tiempos Unix son particularmente significativas.

El time_ttipo de datos Unix que representa un punto en el tiempo es, en muchas plataformas, un entero con signo , tradicionalmente de 32 bits (pero ver más abajo), que codifica directamente el número de tiempo Unix como se describe en la sección anterior. Ser de 32 bits significa que cubre un rango de aproximadamente 136 años en total. La fecha mínima representable es el viernes 1901-12-13, y la fecha máxima representable es el martes 2038-01-19. Un segundo después de las 03:14:07 UTC 2038-01-19, esta representación se desbordará . Este hito se anticipa con una mezcla de diversión y pavor; consulte el problema del año 2038 .  

En algunos sistemas operativos más nuevos, time_tse ha ampliado a 64 bits. Esto expande los tiempos representables en aproximadamente 293 mil millones de años en ambas direcciones, que es más de veinte veces la edad actual del universo por dirección.

Originalmente hubo cierta controversia sobre si el Unix time_tdebería estar firmado o no. Si no está firmado, su rango en el futuro se duplicaría, posponiendo el desbordamiento de 32 bits (68 años). Sin embargo, entonces sería incapaz de representar tiempos anteriores a la época. El consenso time_tdebe firmarse, y esta es la práctica habitual. La plataforma de desarrollo de software para la versión 6 del sistema operativo QNX tiene 32 bits sin firmar time_t, aunque las versiones anteriores usaban un tipo firmado.

Las especificaciones POSIX y Open Group Unix incluyen la biblioteca estándar C , que incluye los tipos de tiempo y las funciones definidas en el <time.h>archivo de encabezado. El estándar ISO C establece que time_tdebe ser un tipo aritmético, pero no exige ningún tipo o codificación específicos para él. POSIX requiere time_tser un tipo entero, pero no exige que esté firmado o no firmado.

Unix no tiene la tradición de representar directamente números de tiempo Unix no enteros como fracciones binarias. En cambio, los tiempos con una precisión inferior a un segundo se representan utilizando tipos de datos compuestos que constan de dos enteros, el primero es a time_t(la parte integral del tiempo Unix) y el segundo es la parte fraccionaria del número de tiempo en millonésimas (pulgadas struct timeval). o mil millonésimas (pulgadas struct timespec). ^{[13] [14]} Estas estructuras proporcionan un formato de datos de coma fija con base decimal , que es útil para algunas aplicaciones y trivial de convertir para otras.

Base UTC

La forma actual de UTC, con segundos intercalares, se define solo a partir del 1 de enero de 1972. Antes de eso, desde el 1 de enero de 1961 había una forma más antigua de UTC en la que no solo había pasos de tiempo ocasionales, que eran por números no enteros número de segundos, pero también el segundo UTC era un poco más largo que el segundo SI, y cambiaba periódicamente para aproximarse continuamente a la rotación de la Tierra. Antes de 1961 no había UTC, y antes de 1958 no existía un cronometraje atómico generalizado ; en estas épocas, se utilizó alguna aproximación de GMT (basada directamente en la rotación de la Tierra) en lugar de una escala de tiempo atómica. ^{[ cita requerida ]}

La definición precisa de la hora Unix como una codificación de UTC solo es controvertida cuando se aplica a la forma actual de UTC. La época Unix anterior al inicio de esta forma de UTC no afecta su uso en esta era: el número de días desde el 1 de enero de 1970 (la época Unix) hasta el 1 de enero de 1972 (el inicio de UTC) no está en duda, y el número de días es todo lo que es significativo para el tiempo de Unix.

El significado de los valores de tiempo de Unix a continuación [phone] (es decir, antes del 1 de enero de 1972) no está definido con precisión. La base de tales tiempos Unix se entiende mejor como una aproximación no especificada de UTC. En cualquier caso, las computadoras de esa época rara vez tenían relojes con la suficiente precisión para proporcionar marcas de tiempo significativas por debajo de un segundo. El tiempo Unix no es una forma adecuada de representar tiempos anteriores a 1972 en aplicaciones que requieren una precisión inferior a un segundo; tales aplicaciones deben, al menos, definir qué forma de UT o GMT utilizan.

A partir de 2009 ^[actualizar], se está considerando la posibilidad de terminar con el uso de segundos intercalares en tiempo civil. ^[15] Un medio probable para ejecutar este cambio es definir una nueva escala de tiempo, llamada Hora Internacional , que inicialmente coincide con UTC pero a partir de entonces no tiene segundos intercalares, por lo que permanece en un desplazamiento constante de TAI. Si esto sucede, es probable que la hora de Unix se defina prospectivamente en términos de esta nueva escala de tiempo, en lugar de UTC. La incertidumbre acerca de si esto ocurrirá hace que el tiempo Unix prospectivo no sea menos predecible de lo que ya es: si UTC simplemente no tuviera más segundos intercalares, el resultado sería el mismo.

Historia

Esta sección necesita citas adicionales para su verificación . Por favor, ayuda a mejorar este artículo mediante la adición de citas de fuentes confiables . El material no obtenido puede ser cuestionado y eliminado. ( Septiembre de 2019 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

Las primeras versiones de la hora Unix tenían un número entero de 32 bits que se incrementaba a una frecuencia de 60  Hz , que era la frecuencia del reloj del sistema en el hardware de los primeros sistemas Unix. Como resultado, el valor de 60 Hz todavía aparece en algunas interfaces de software. La época también difirió del valor actual. La primera edición del Manual del programador de Unix con fecha del 3 de noviembre de 1971 define la hora Unix como "el tiempo desde las 00:00:00, el 1 de enero de 1971, medido en sesentavos de segundo". ^[dieciséis]

El Manual del Usuario también comentó que "el usuario con mentalidad cronológica notará que 2 ** 32 sexagésimas de segundo son solo alrededor de 2.5 años". Debido a este rango limitado, la época se redefinió más de una vez, antes de que la frecuencia se cambiara a 1 Hz y la época se estableciera en su valor actual del 1 de enero de 1970 a las 00:00:00 UTC. Esto arrojó un rango de aproximadamente 136 años, la mitad antes de 1970 y la mitad después.

Como lo indica la definición citada anteriormente, la escala de tiempo de Unix fue originalmente pensada para ser una simple representación lineal del tiempo transcurrido desde una época. Sin embargo, no se consideraron los detalles de las escalas de tiempo, y se asumió implícitamente que había una escala de tiempo lineal simple ya disponible y acordada. La definición del manual de la primera edición ni siquiera especifica qué zona horaria se utiliza. Varios problemas posteriores, incluida la complejidad de la definición actual, resultan de que el tiempo de Unix se ha definido gradualmente por el uso en lugar de estar completamente definido desde el principio.

Cuando se escribió POSIX.1 , surgió la pregunta de cómo definir con precisión time_tfrente a los segundos bisiestos. El comité POSIX consideró si el tiempo Unix debería seguir siendo, como se pretendía, una cuenta lineal de segundos desde la época, a expensas de la complejidad en las conversiones con tiempo civil o una representación del tiempo civil, a expensas de la inconsistencia alrededor de los segundos intercalares. Los relojes de computadora de la época no se establecieron con la suficiente precisión para sentar un precedente en un sentido u otro.

El comité POSIX se dejó influir por argumentos en contra de la complejidad de las funciones de la biblioteca, ^{[ cita requerida ]} y definió firmemente la hora Unix de una manera simple en términos de los elementos de la hora UTC. Esta definición era tan simple que ni siquiera abarcaba toda la regla de los años bisiestos del calendario gregoriano, y convertiría el 2100 en un año bisiesto.

La edición de 2001 de POSIX.1 rectificó la regla defectuosa de los años bisiestos en la definición de tiempo Unix, pero retuvo la definición esencial de tiempo Unix como una codificación de UTC en lugar de una escala de tiempo lineal. Desde mediados de la década de 1990, los relojes de las computadoras se han configurado de forma rutinaria con la precisión suficiente para que esto sea importante, y generalmente se han configurado utilizando la definición de hora Unix basada en UTC. Esto ha resultado en una complejidad considerable en las implementaciones de Unix, y en el Protocolo de tiempo de red , para ejecutar pasos en el número de tiempo de Unix cada vez que ocurren los segundos intercalares. ^{[ cita requerida ]}

Eventos notables en la época de Unix

Los entusiastas de Unix tienen un historial de celebrar "fiestas time_t" (pronunciado " fiestas de té en el tiempo ") para celebrar valores significativos del número de tiempo Unix. ^{[17] [18]} Estos son directamente análogos a las celebraciones de año nuevo que ocurren en el cambio de año en muchos calendarios. A medida que el uso de Unix se ha extendido, también lo ha hecho la práctica de celebrar sus hitos. Por lo general, son los valores de tiempo que son números redondos en decimal los que se celebran, siguiendo la convención de Unix de ver los time_tvalores en decimal. Entre algunos grupos también se celebran los números binarios redondos , como el +2 ³⁰ que ocurrió a las 13:37:04 UTC del sábado 10 de enero de 2004. ^{[cita requerida ]}

Los eventos que celebran se describen típicamente como " N segundos desde la época de Unix", pero esto es inexacto; como se discutió anteriormente, debido al manejo de los segundos intercalares en el tiempo de Unix, el número de segundos transcurridos desde la época de Unix es ligeramente mayor que el número de tiempo de Unix para los tiempos posteriores a la época.

• A las 18:36:57 UTC del miércoles 17 de octubre de 1973, tuvo lugar la primera aparición de la fecha en formato ISO 8601 ^[a] (1973-10-17) dentro de los dígitos de la hora Unix (119731017).
• A las 01:46:40 UTC del domingo 9 de septiembre de 2001, el billennium de Unix (número de tiempo de Unix 1 000 000 000 ) se celebró. ^[19] El nombre Billennium es un baúl de viaje de mil millones y milenio . ^{[20] [21]} Algunos programas que almacenaron marcas de tiempo usando una representación de texto encontraron errores de clasificación, como en un texto de tiempos de clasificación después de la rotación, comenzando con 1 dígito, ordenados erróneamente antes de tiempos anteriores comenzando con 9 dígitos. Los programas afectados incluyeron el popular lector de Usenet KNode y el cliente de correo electrónico KMail , parte de KDE.entorno de escritorio. Estos errores eran generalmente de naturaleza cosmética y se solucionaban rápidamente una vez que los problemas se volvían evidentes. El problema también afectó a muchos filtros de formato de documento de Filtrix proporcionados con las versiones de WordPerfect para Linux ; La comunidad de usuarios creó un parche para resolver este problema, ya que Corel ya no vendía ni admitía esa versión del programa. ^[22]
• A las 23:31:30 UTC del viernes 13 de febrero de 2009, se alcanzó la representación decimal de la hora Unix1 234 567 890 segundos. ^[23] Google celebró esto con un doodle de Google . ^[24] Se llevaron a cabo fiestas y otras celebraciones en todo el mundo, entre varias subculturas técnicas, para celebrar la1 234 567 890 segundo. ^{[17] [25]}
• A las 03:33:20 UTC del miércoles 18 de mayo de 2033, el valor de tiempo de Unix será igual 2 000 000 000 de segundos.
• A las 06:28:16 UTC del jueves 7 de febrero de 2036, el protocolo de tiempo de red pasará a la siguiente época, ya que el valor de marca de tiempo de 32 bits utilizado en NTP (sin firmar, pero basado en el 1 de enero de 1900) se desbordará. Esta fecha está cerca de la fecha siguiente porque el rango de 136 años de un número entero de segundos de 32 bits está cerca del doble del desplazamiento de 70 años entre las dos épocas.
• A las 03:14:08 UTC del martes 19 de enero de 2038, las versiones de 32 bits de la marca de tiempo de Unix dejarán de funcionar, ya que desbordarán el valor más grande que se puede mantener en un número firmado de 32 bits ( 7FFFFFFF 16 o2 147 483 647 ). Antes de este momento, el software que usa sellos de tiempo de 32 bits deberá adoptar una nueva convención para sellos de tiempo, ^[26] y los formatos de archivo que usan sellos de tiempo de 32 bits deberán cambiarse para admitir sellos de tiempo más grandes o una época diferente. Si no se modifica, el siguiente segundo se interpretará incorrectamente como 20:45:52 del viernes 13 de diciembre de 1901 UTC . Esto se conoce como el problema del año 2038 .
• A las 05:20:00 UTC del sábado 24 de enero de 2065, el valor de tiempo de Unix será igual 3 000 000 000 segundos.
• A las 06:28:15 UTC del domingo 7 de febrero de 2106, la hora Unix llegará a FFFFFFFF 16 o4 294 967 295 segundos que, para los sistemas que mantienen el tiempo en enteros sin signo de 32 bits, es el máximo alcanzable. Para algunos de estos sistemas, el segundo siguiente se interpretará incorrectamente como 00:00:00 del jueves 1 de enero de 1970 UTC . Otros sistemas pueden experimentar un error de desbordamiento con resultados impredecibles. ^{[ cita requerida ]}
• A las 15:30:08 UTC del domingo 4 de diciembre 292 277 026 596 , ^{[27] [28]} Las versiones de 64 bits de la marca de tiempo de Unix dejan de funcionar, ya que desbordarán el valor más grande que se puede mantener en un número de 64 bits con signo. Esto es casi 22 veces la edad actual estimada del universo , que es1,37 × 10 ¹⁰ años (13,7 mil millones).

En literatura y calendáricos

La novela de Vernor Vinge , A Deepness in the Sky, describe una civilización comercial espacial miles de años en el futuro que todavía usa la época Unix. El " programador-arqueólogo " responsable de encontrar y mantener código utilizable en sistemas informáticos maduros primero cree que la época se refiere al momento en que el hombre caminó por primera vez sobre la Luna , pero luego se da cuenta de que es "el segundo 0 de uno de los primeros tiempos de la humanidad. sistemas operativos informáticos ". ^[29]

Ver también

• Época (informática)
• hora del sistema

Notas

1. citado retroactivamente desde que se publicó la norma ISO 8601 en 1988.

Referencias

1. "El problema 7 de especificaciones de base de grupo abierto, fundamento: definiciones de base, sección A.4 Conceptos generales" . El grupo abierto . Consultado el 9 de septiembre de 2019 .
2. "Las especificaciones básicas de Open Group Issue 7, sección 4.16 Segundos desde la época" . El grupo abierto . Consultado el 22 de enero de 2017 .
3. Mateo, Neil; Piedras, Richard (2008). "El entorno Linux". Inicio de la programación de Linux . Indianápolis, Indiana, Estados Unidos: Wiley. pag. 148. ISBN 978-0-470-14762-7.
4. "El número 7 de especificaciones de base de grupo abierto, fundamento, sección 4.16 segundos desde la época" . El OpenGroup . Consultado el 22 de enero de 2017 .
5. date  - Referencia de comandos y utilidades, la especificación única de UNIX , número 7 de The Open Group
6. "Epoch Converter - Convertidor de marca de tiempo Unix" . Convertidor de época . Consultado el 12 de enero de 2020 .
7. "Manejo de marcas de tiempo usando formato de fecha en accesos directos" . Apple . Consultado el 19 de junio de 2019 .
8. "Formato de fecha RAW en informes exportados CSV" . Corporación de Máquinas de Negocios Internacionales (IBM) . Consultado el 19 de junio de 2019 .
9. "TIMESTAMP BY (Azure Stream Analytics)" . Microsoft Corporation . Consultado el 19 de junio de 2019 .
10. Mills, David L. (12 de mayo de 2012). "La escala de tiempo NTP y los segundos bisiestos" . eecis.udel.edu . Consultado el 21 de agosto de 2017 .
11. "Escalas de tiempo" . Wiki de protocolo de tiempo de red . 24 de julio de 2019 . Consultado el 12 de enero de 2020 .
12. Markus Kuhn. "API modernizada para ISO C" . www.cl.cam.ac.uk .
13. "timespec" . Páginas del manual de NetBSD . 12 de abril de 2011 . Consultado el 5 de julio de 2019 .
14. "tiempo.h (0P)" . Página del manual de Linux . Consultado el 5 de julio de 2019 .
15. McCarthy, DD ; Seidelmann, PK (2009). TIEMPO: de la rotación de la Tierra a la física atómica . Weinheim: Wiley – VCH Verlag GmbH & Co. KGaA. pag. 232. ISBN 978-3-527-40780-4.
16. Manual del programador de Unix (PDF) (1ª ed.). 3 de noviembre de 1971 . Consultado el 28 de marzo de 2012 . time devuelve el tiempo transcurrido desde las 00:00:00 del 1 de enero de 1971, medido en sesentavos de segundo.
17. Tweney, Dylan (12 de febrero de 2009). "Amantes de Unix a la fiesta como si fuera 1234567890" . Cableado .
18. "Slashdot | fecha +% s girando 1111111111" . 17 de marzo de 2005.^{[ fuente no confiable? ]}
19. "Datos de tiempo de Unix y trivia - Tiempo de Unix. Información" . Archivado desde el original el 27 de octubre de 2017.
20. "UNIX se acerca a la vejez madura de mil millones" . Electromagnetic.net. Archivado desde el original el 13 de abril de 2013 . Consultado el 6 de diciembre de 2012 .
21. "Volumen 21 del resumen de riesgos: número 69" . Catless.ncl.ac.uk . Consultado el 6 de diciembre de 2012 .
22. "Problemas técnicos" . linuxmafia.com . Consultado el 21 de agosto de 2017 .
23. nixCraft. "Humor: el viernes 13 de febrero de 2009, la hora de Unix será 1234567890" . Cyberciti.biz . Consultado el 6 de diciembre de 2012 .
24. "Logotipo de Google 1234567890" . Google Inc . Consultado el 28 de enero de 2013 .
25. Ahmed, Murad (13 de febrero de 2009). "En el tercer golpe, la hora Unix será 1234567890" . The Times .
26. "Unix Time Stamp.com" . UnixTimeStamp.com . Consultado el 12 de enero de 2020 .
27. Spinellis, Diomidis (7 de abril de 2006). Calidad del código: la perspectiva del código abierto . ISBN 9780321166074.
28. Documento de trabajo de IDRBT No. 9 Y2K38 - Ashutosh Saxena y Sanjay Rawat
29. Mashey, John R. (27 de diciembre de 2004). "Idiomas, niveles, bibliotecas y longevidad" . Cola . 2 (9): 32–38. doi : 10.1145 / 1039511.1039532 . S2CID 28911378 . 

Enlaces externos

• Manual del programador de Unix, primera edición
• Relato personal de las decisiones POSIX de Landon Curt Noll
• Clewett, James. 2,147,483,647 - El fin de los tiempos [Unix] .
• Algoritmos de fecha de bajo nivel compatibles con crono : algoritmos para convertir entre fechas gregorianas y julianas y el número de días desde el inicio de la hora de Unix
• Herramientas de conversión de marcas de tiempo de Epoch y Unix