Tiempo de Unix

El tiempo Unix ^[a] es una representación de fecha y hora ampliamente utilizada en informática . Mide el tiempo por la cantidad de segundos no intercalares que han transcurrido desde las 00:00:00 UTC del 1 de enero de 1970, la época Unix . En la informática moderna, los valores a veces se almacenan con mayor granularidad , como microsegundos o nanosegundos .

El horario Unix se originó como el horario del sistema de los sistemas operativos Unix . Se ha utilizado ampliamente en otros sistemas operativos de computadoras , sistemas de archivos , lenguajes de programación y bases de datos .

Actualmente, el tiempo Unix se define como el número de segundos no intercalares que han transcurrido desde las 00:00:00  UTC del jueves 1 de enero de 1970, lo que se conoce como la época Unix . ^[3] El tiempo Unix normalmente se codifica como un entero con signo .

La época de Unix0 es exactamente la medianoche UTC del 1 de enero de 1970, y el tiempo Unix se incrementa en 1 por cada segundo no intercalar después de esto. Por ejemplo, 00:00:00  UTC del 1 de enero de 1971 se representa en tiempo Unix como31 536 000 . Los valores negativos, en los sistemas que los admiten, indican tiempos anteriores a la época Unix, y el valor disminuye en 1 por cada segundo no intercalar antes de la época. Por ejemplo, las 00:00:00  UTC del 1 de enero de 1969 se representan en tiempo Unix como−31 536 000. Cada día en tiempo Unix consta exactamente de86 400 segundos.

El tiempo Unix a veces se denomina tiempo de época . Esto puede ser engañoso, ya que el tiempo Unix no es el único sistema de tiempo basado en una época y la época Unix no es la única época utilizada por otros sistemas de tiempo. ^[5]

El tiempo Unix difiere tanto del Tiempo Universal Coordinado (UTC) como del Tiempo Atómico Internacional (TAI) en su manejo de los segundos intercalares . El UTC incluye segundos intercalares que se ajustan a la discrepancia entre el tiempo preciso, medido por los relojes atómicos , y el tiempo solar , relacionado con la posición de la Tierra en relación con el Sol. El Tiempo Atómico Internacional (TAI), en el que cada día es preciso86 400 segundos de duración, ignora el tiempo solar y pierde gradualmente la sincronización con la rotación de la Tierra a un ritmo de aproximadamente un segundo por año. En el tiempo Unix, cada día contiene exactamente86 400 segundos. Cada segundo intercalar utiliza la marca de tiempo de un segundo que lo precede o lo sigue inmediatamente. ^[3]

En un día UTC normal, que tiene una duración de86 400 segundos, el número de tiempo 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:

Cuando se produce un segundo intercalar , el día UTC no es exactamente86 400 segundos de duración y el número de tiempo Unix (que siempre aumenta exactamente en86 400 cada día) experimenta una discontinuidad . Los segundos intercalares pueden ser positivos o negativos. Nunca se ha declarado un segundo intercalar negativo, pero si se declarara uno, entonces 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, lo que ocurre aproximadamente cada año y medio en promedio, el número de tiempo Unix aumenta continuamente hasta el día siguiente durante el segundo intercalar y luego, al final del segundo intercalar, retrocede en 1 (regresando al comienzo del día siguiente). Por ejemplo, esto es lo que sucedió en los sistemas POSIX.1 estrictamente conformes a fines de 1998:

Los números de tiempo Unix se repiten en el segundo inmediatamente posterior a un segundo intercalar positivo. El número de tiempo Unix1 483 228 800 es, por tanto, ambiguo: puede referirse tanto al inicio del segundo intercalar (2016-12-31 23:59:60) como al final del mismo, un segundo después (2017-01-01 00:00:00). En el caso teórico en el que 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 hacen referencia a ningún punto en el tiempo UTC.

Un reloj Unix suele implementarse con un tipo diferente de manejo de segundos intercalares positivos asociado con el Protocolo de tiempo de red (NTP). Esto produce un sistema que no cumple con el estándar POSIX. Consulte la sección a continuación sobre NTP para obtener más detalles.

Cuando se trabaja con períodos que no incluyen 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. Esta es una técnica computacional común. Sin embargo, cuando hay segundos intercalares, estos 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 trabaja con tiempos Unix, y a menudo es preferible utilizar una codificación de tiempo diferente que no sufra este problema.

Un número de tiempo Unix se puede convertir fácilmente en un tiempo UTC tomando el cociente y el módulo del número de tiempo Unix, módulo86 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 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 esté durante un segundo intercalar. Si se da un número de tiempo Unix que no es válido debido a un segundo intercalar negativo, genera un tiempo UTC igualmente inválido. Si estas condiciones son significativas, es necesario consultar una tabla de segundos intercalares para detectarlas.

Generalmente, se implementa un reloj Unix al estilo de Mills con un manejo del segundo intercalar que no es sincrónico con el cambio del número de tiempo Unix. El número de tiempo disminuye inicialmente donde debería haberse producido un salto y luego salta al tiempo correcto 1 segundo después del salto. Esto hace que la implementación sea más sencilla y se describe en el artículo de Mills. ^[6] Esto es lo que sucede en un segundo intercalar positivo:

Esto se puede descifrar correctamente prestando atención a la variable de estado del segundo intercalar, que indica de forma inequívoca si el salto ya se ha realizado. El cambio de la variable de estado es sincrónico con el salto.

Una situación similar se produce con un segundo intercalar negativo, en el que el segundo que se salta es ligeramente demasiado tarde. Por un breve tiempo, el sistema muestra un número de tiempo nominalmente imposible, pero esto se puede detectar mediante el estado TIME_DEL y corregir.

En este tipo de sistema, el número de tiempo Unix viola el 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 el tiempo UTC completo 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, y luego indicando TIME_WAIT durante la totalidad del segundo siguiente mientras se repite el conteo de segundos. Esto requiere un manejo sincrónico del segundo intercalar. 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.

Otra variante, mucho más rara y no conforme, del registro de la hora de Unix implica incrementar el valor de todos los segundos, incluidos los segundos intercalares; ^[7] algunos sistemas Linux están configurados de esta manera. ^[8] El registro de la hora de esta manera a veces se denomina "TAI" (aunque las marcas de tiempo se pueden convertir a UTC si el valor corresponde a una hora en la que se conoce la diferencia entre TAI y UTC), en oposición a "UTC" (aunque no todos los valores de tiempo UTC tienen una referencia única en sistemas que no cuentan los segundos intercalares). ^[8]

Como el TAI no tiene segundos intercalares y cada día TAI dura exactamente 86400 segundos, esta codificación es en realidad un recuento lineal puro de los segundos transcurridos desde el 1 de enero de 1970 a las 00:00:10  TAI. Esto hace que la aritmética de intervalos de tiempo sea mucho más sencilla. 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 realizar la conversión correcta entre UTC y la representación de tiempo pseudo-Unix. Esto se asemeja a la manera en que se deben consultar las tablas de zonas horarias para realizar la conversión entre la hora civil y la hora local ; la base de datos de zonas horarias de la IANA incluye información sobre segundos intercalares, y el código de muestra disponible en la misma fuente utiliza esa información para realizar la conversión entre las marcas de tiempo basadas en TAI y la hora local. La conversión también presenta problemas de definición antes del comienzo en 1972 de la forma actual de UTC (véase la sección Base de UTC más adelante).

Este sistema, a pesar de su parecido superficial, no es tiempo Unix. Codifica tiempos con valores que difieren en varios segundos de los valores de tiempo POSIX. Se propuso una versión de este sistema, en la que la época era 1970-01-01T00:00:00  TAI en lugar de 1970-01-01T00:00:10  TAI, para su inclusión en el C de ISO time.h, pero solo la parte UTC fue aceptada en 2011. ^[9] Sin embargo tai_clock, existe en C++20.

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

El tipo de datos Unix time_tque representa un punto en el tiempo es, en muchas plataformas, un entero con signo , tradicionalmente de 32 bits (pero vea más abajo), que codifica directamente el número de tiempo Unix como se describe en la sección anterior. Un valor con signo de 32 bits cubre aproximadamente 68 años antes y después de la época 1970-01-01. 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 2038-01-19T03:14:07Z esta representación se desbordará en lo que se conoce como el problema del año 2038 . 

En algunos sistemas operativos más nuevos, time_tse ha ampliado a 64 bits. Esto amplía los tiempos representables a unos 292.300 millones de años en ambas direcciones, lo que supone más de veinte veces la edad actual del universo .

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

Las especificaciones POSIX y Open Group de 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_tque sea un tipo entero, pero no exige que sea con signo o sin signo.

Unix no tiene tradición de representar directamente números de tiempo Unix no enteros como fracciones binarias. En cambio, los tiempos con precisión de subsegundos se representan utilizando tipos de datos compuestos que consisten en dos números enteros, siendo el primero a time_t(la parte integral del tiempo Unix) y el segundo la parte fraccionaria del número de tiempo en millonésimas (en struct timeval) o milmillonésimas (en struct timespec). ^{[10] [11]} Estas estructuras proporcionan un formato de datos de punto fijo basado en decimal , que es útil para algunas aplicaciones y trivial de convertir para otras.

La forma actual del UTC, con segundos intercalares, se definió recién a partir del 1 de enero de 1972. Antes de eso, desde el 1 de enero de 1961, existía una forma más antigua del UTC en la que no solo había pasos de tiempo ocasionales, que se expresaban en números no enteros de segundos, sino que además el segundo UTC era ligeramente 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 existía el UTC, y antes de 1958 no había un cronometraje atómico generalizado ; en estas épocas, se utilizaba alguna aproximación del 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 del tiempo Unix como codificación del UTC solo es indiscutible cuando se aplica a la forma actual del 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 del UTC) no está en cuestión, y el número de días es lo único que tiene importancia para el tiempo Unix.

El significado de los valores de tiempo de Unix que aparecen a continuaciónEl +63 072 000 (es decir, antes del 1 de enero de 1972) no está definido con precisión. La mejor manera de entender la base de dichos tiempos Unix es que sea una aproximación no especificada de UTC. Las computadoras de esa época rara vez tenían relojes configurados con la precisión suficiente para proporcionar marcas de tiempo significativas en subsegundos en cualquier caso. El tiempo Unix no es una forma adecuada de representar tiempos anteriores a 1972 en aplicaciones que requieren una precisión de subsegundos; dichas 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 el tiempo civil. ^[12] Un medio probable para ejecutar este cambio es definir una nueva escala de tiempo, llamada Tiempo Internacional ^{[ cita requerida ]} , que inicialmente coincida con UTC pero que luego no tenga segundos intercalares, permaneciendo así en una diferencia constante con respecto al TAI. Si esto sucede, es probable que el tiempo Unix se defina prospectivamente en términos de esta nueva escala de tiempo, en lugar de UTC. La incertidumbre sobre 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.

Esta sección necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo agregando citas de fuentes confiables en esta sección. El material sin fuentes puede ser cuestionado y eliminado. ( Septiembre de 2019 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Las primeras versiones de la hora Unix tenían un entero de 32 bits que se incrementaba a una velocidad de 60  Hz , que era la velocidad del reloj del sistema en el hardware de los primeros sistemas Unix. Las marcas de tiempo almacenadas de esta manera solo podían representar un rango de poco más de dos años y cuarto. La época desde la que se contaba se cambió con las versiones de Unix para evitar el desbordamiento, y la medianoche del 1 de enero de 1971 y el 1 de enero de 1972 se usaron como épocas durante el desarrollo temprano de Unix. Las primeras definiciones de la hora Unix también carecían de zonas horarias. ^{[13] [14]}

Los ingenieros de Unix seleccionaron arbitrariamente la época actual del 1 de enero de 1970 a las 00:00:00 UTC porque la consideraron una fecha conveniente para trabajar. La precisión se modificó para contar en segundos con el fin de evitar un desbordamiento a corto plazo. ^[1]

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

El comité POSIX se dejó influenciar por los argumentos en contra de la complejidad de las funciones de la biblioteca, ^{[ cita requerida ]} y definió firmemente el tiempo Unix de una manera simple en términos de los elementos del tiempo 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 año 2100 en un año bisiesto.

La edición 2001 de POSIX.1 corrigió la regla errónea de los años bisiestos en la definición del tiempo Unix, pero mantuvo la definición esencial del 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 manera rutinaria con la precisión suficiente para que esto sea importante, y lo más común es que se configuren utilizando la definición de tiempo 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 Unix cada vez que ocurren segundos bisiestos. ^{[ cita requerida ]}

El tiempo Unix se adopta ampliamente en informática más allá de su aplicación original como el tiempo del sistema para Unix . El tiempo Unix está disponible en casi todas las API de programación del sistema, incluidas las proporcionadas por los sistemas operativos basados ​​en Unix y no basados ​​en Unix . Casi todos los lenguajes de programación modernos proporcionan API para trabajar con el tiempo Unix o convertirlos a otra estructura de datos. El tiempo Unix también se utiliza como un mecanismo para almacenar marcas de tiempo en varios sistemas de archivos , formatos de archivos y bases de datos .

La biblioteca estándar de C utiliza el tiempo Unix para todas las funciones de fecha y hora, y el tiempo Unix a veces se conoce como time_t, el nombre del tipo de datos utilizado para las marcas de tiempo en C y C++ . Las funciones de tiempo Unix de C se definen como la API de tiempo del sistema en la especificación POSIX . ^[15] La biblioteca estándar de C se utiliza ampliamente en todos los sistemas operativos de escritorio modernos, incluidos Microsoft Windows y sistemas similares a Unix como macOS y Linux , donde es una interfaz de programación estándar. ^{[16] [17] [18]}

iOS proporciona una API Swift que utiliza de forma predeterminada una época del 1 de enero de 2001, pero que también se puede utilizar con marcas de tiempo de Unix. ^[19] Android utiliza la hora de Unix junto con una zona horaria para su API de hora del sistema. ^[20]

Windows no utiliza el tiempo Unix para almacenar el tiempo internamente, pero sí lo utiliza en las API del sistema, que se proporcionan en C++ e implementan la especificación de la biblioteca estándar de C. ^[16] El tiempo Unix se utiliza en el formato PE para los ejecutables de Windows. ^[21]

El tiempo Unix suele estar disponible en los principales lenguajes de programación y se usa ampliamente en la programación de aplicaciones de escritorio, móviles y web. Java proporciona un objeto Instant que contiene una marca de tiempo Unix tanto en segundos como en nanosegundos. ^[22] Python proporciona una biblioteca de tiempo que utiliza el tiempo Unix. ^[23] JavaScript proporciona una biblioteca Date que proporciona y almacena marcas de tiempo en milisegundos desde la época Unix y se implementa en todos los navegadores web modernos de escritorio y móviles, así como en entornos de servidor JavaScript como Node.js. ^[24 ]

Los sistemas de archivos diseñados para su uso con sistemas operativos basados ​​en Unix tienden a utilizar el tiempo Unix. APFS , el sistema de archivos utilizado de forma predeterminada en todos los dispositivos Apple, y ext4 , que se utiliza ampliamente en dispositivos Linux y Android, utilizan el tiempo Unix en nanosegundos para las marcas de tiempo de los archivos. ^{[25] [26]} Varios formatos de archivos de almacenamiento pueden almacenar marcas de tiempo en tiempo Unix, incluidos RAR y tar . ^{[27] [28]} El tiempo Unix también se utiliza comúnmente para almacenar marcas de tiempo en bases de datos, incluidas MySQL y PostgreSQL . ^{[29] [30]}

El sistema Unix Time fue diseñado para codificar fechas y horas del calendario de una manera compacta, pensada para su uso interno por parte de las computadoras. No está pensado para que los humanos lo puedan leer fácilmente ni para almacenar valores que dependen de la zona horaria. Además, está limitado por defecto a representar el tiempo en segundos, lo que lo hace inadecuado para su uso cuando se necesita una medición más precisa del tiempo, como cuando se mide el tiempo de ejecución de los programas. ^[31]

El tiempo Unix por diseño no requiere un tamaño específico para el almacenamiento, pero las implementaciones más comunes del tiempo Unix usan un entero con signo con el mismo tamaño que el tamaño de palabra del hardware subyacente. Como la mayoría de las computadoras modernas son de 32 bits o 64 bits , y una gran cantidad de programas aún se escriben en modo de compatibilidad de 32 bits, esto significa que muchos programas que usan el tiempo Unix usan campos enteros con signo de 32 bits. El valor máximo de un entero con signo de 32 bits es 2 ³¹ − 1 , y el valor mínimo es −2 ³¹ , lo que hace imposible representar fechas anteriores al 13 de diciembre de 1901 (a las 20:45:52 UTC) o posteriores al 19 de enero de 2038 (a las 03:14:07 UTC). El corte temprano puede tener un impacto en las bases de datos que almacenan información histórica; En algunas bases de datos donde se utiliza el tiempo Unix de 32 bits para las marcas de tiempo, puede ser necesario almacenar el tiempo en un formato de campo diferente, como una cadena, para representar fechas anteriores a 1901. El corte tardío se conoce como el problema del año 2038 y tiene el potencial de causar problemas a medida que se acerca la fecha, ya que las fechas posteriores al corte de 2038 volverían al inicio del rango representable en 1901. ^{[31] : 60}

Los límites de rango de fechas no son un problema con las representaciones de 64 bits de tiempo Unix, ya que el rango efectivo de fechas representables con tiempo Unix almacenado en un entero de 64 bits con signo es de más de 584 mil millones de años, o 292 mil millones de años en cualquier dirección de la época de 1970. ^{[31] : 60-61  [32]}

El tiempo Unix no es el único estándar para el tiempo que cuenta a partir de una época. En Windows , el FILETIMEtipo almacena el tiempo como un recuento de intervalos de 100 nanosegundos que han transcurrido desde las 0:00 GMT del 1 de enero de 1601. ^[33] El tiempo de época de Windows se utiliza para almacenar marcas de tiempo para archivos ^[34] y en protocolos como el Servicio de hora de Active Directory ^[35] y el Bloque de mensajes del servidor .

El Protocolo de Tiempo de Red utilizado para coordinar el tiempo entre computadoras utiliza una época del 1 de enero de 1900, contada en un entero sin signo de 32 bits para los segundos y otro entero sin signo de 32 bits para los segundos fraccionarios, que se renueva cada 2 ³² segundos (aproximadamente una vez cada 136 años). ^[36]

Muchas aplicaciones y lenguajes de programación proporcionan métodos para almacenar la hora con una zona horaria explícita. ^[37] También existen varios estándares de formato de hora que pueden ser leídos tanto por humanos como por computadoras, como ISO 8601 .

Los entusiastas de Unix tienen una historia de celebrar "fiestas time_t" (pronunciadas " fiestas del té del tiempo ") para celebrar valores significativos del número de tiempo Unix. ^{[38] [39]} Estas son directamente análogas a las celebraciones de año nuevo que ocurren en el cambio de año en muchos calendarios. A medida que el uso del tiempo 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 Unix de ver time_tlos valores en decimal. Entre algunos grupos también se celebran los números binarios redondos , como +2 ³⁰ que ocurrió a las 13:37:04 UTC del sábado 10 de enero de 2004. ^{[ cita requerida ]}

Los eventos que estos celebran se describen típicamente como " N segundos desde la época Unix", pero esto es inexacto; como se discutió anteriormente, debido al manejo de los segundos intercalares en el tiempo Unix, el número de segundos transcurridos desde la época Unix es ligeramente mayor que el número de tiempo Unix para 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 ^[b] (1973-10-17) dentro de los dígitos del tiempo Unix (119731017).
• A las 01:46:40 UTC del domingo 9 de septiembre de 2001, el billennium Unix (número de tiempo Unix)1 000 000 000 ) fue celebrado. ^[40] El nombre billennium es un acrónimo de billion y millennium . ^{[41] [42]} Algunos programas que almacenaban marcas de tiempo usando una representación de texto encontraron errores de ordenación, como en una ordenación de texto, las horas después del cambio que comienzan con un dígito 1 se ordenaron erróneamente antes de horas anteriores que comienzan con un dígito 9. Los programas afectados incluyeron el popular lector de Usenet KNode y el cliente de correo electrónico KMail , parte del entorno de escritorio KDE . Dichos errores eran generalmente de naturaleza cosmética y se solucionaban rápidamente una vez que los problemas se hacían evidentes. ^{[ cita requerida ]} El problema también afectó a muchos filtros de formato de documento Filtrix proporcionados con versiones Linux de WordPerfect ; la comunidad de usuarios creó un parche para resolver este problema, ya que Corel ya no vendía ni daba soporte a esa versión del programa. ^[43]
• A las 23:31:30 UTC del viernes 13 de febrero de 2009, la representación decimal del tiempo Unix alcanzó1 234 567 890 segundos. ^[44] Google celebró esto con un doodle de Google . ^[45] Se llevaron a cabo fiestas y otras celebraciones en todo el mundo, entre varias subculturas técnicas, para celebrar el1 234 567 890 segundo. ^{[38] [46]}

La novela de Vernor Vinge, A Deepness in the Sky, describe una civilización comercial que viaja por el espacio miles de años en el futuro y que todavía utiliza la era Unix. El " programador-arqueólogo " responsable de encontrar y mantener el código utilizable en sistemas informáticos maduros cree primero 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 sistemas operativos informáticos de la humanidad". ^[47]

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

Wikiversidad tiene recursos de aprendizaje sobre JavaScript/Conversor de tiempo Epoch

• Manual del programador de Unix, primera edición
• Relato personal de Landon Curt Noll sobre las decisiones POSIX
• Algoritmos de fecha de bajo nivel compatibles con chrono: algoritmos para convertir entre fechas gregorianas y julianas y el número de días desde el inicio del tiempo Unix