Tiempo Unix - Unix time

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 tiempo de época , tiempo de Posix , segundos desde la época o tiempo de época UNIX ) es un sistema para describir un punto en el tiempo . Es el número de segundos que han transcurrido desde la época de Unix , excluidos los segundos intercalares . La época de Unix es a las 00:00:00 UTC del 1 de enero de 1970 (una fecha arbitraria). El tiempo Unix no es lineal y un segundo intercalar tiene el mismo tiempo Unix que el segundo anterior (o posterior, dependiendo de la implementación), de modo que cada día se trata como si contuviera exactamente86 400 segundos, sin segundos agregados o restados del día como resultado de segundos intercalares positivos o negativos. Debido a este tratamiento de los segundos intercalares, el tiempo de 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.

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. 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. 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.

El tiempo de Unix a veces se denomina, erróneamente, tiempo de época , porque 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 ").

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:

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 de 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:

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íncrona

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. Esto es lo que sucede en un segundo intercalar positivo:

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

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. 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. Se propuso una versión de este sistema para su inclusión en ISO C time.h, pero solo la parte UTC se aceptó en 2011. tai_clockSin embargo, existe A 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á 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 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 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). 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.

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 +63 072 000 (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 en menos 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, se está considerando la posibilidad de terminar con el uso de segundos intercalares en tiempo civil. 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

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".

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 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.

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. 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.

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 (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ó. El nombre Billennium es un baúl de viaje de mil millones y milenio . Algunos programas que las marcas de tiempo almacenados usando una representación de texto encontrado errores de clasificación, como en las épocas de texto ordenar después de la cifra de negocios, comenzando con un 1 dígito, erróneamente ordenados antes de los tiempos anteriores que comienzan con un 9 dígitos. Los programas afectados incluyeron el popular lector de Usenet KNode y el cliente de correo electrónico KMail , parte del entorno de escritorio KDE . 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 que se proporcionan 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.
• 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. Google celebró esto con un doodle de Google . Se llevaron a cabo fiestas y otras celebraciones en todo el mundo, entre varias subculturas técnicas, para celebrar la1 234 567 890 segundo.
• 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 utiliza marcas de tiempo de 32 bits deberá adoptar una nueva convención para las marcas de tiempo, y los formatos de archivo que utilizan marcas de tiempo de 32 bits deberán cambiarse para admitir marcas 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 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.
• A las 15:30:08 UTC del domingo 4 de diciembre 292 277 026 596 , 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 ".

Ver también

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

Notas

Referencias

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