1708540275( )2024-02-21T18:31:15+00:00
La hora Unix [a] es una representación de fecha y hora ampliamente utilizada en informática . Mide el tiempo por el número 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 .
La hora Unix se originó como la hora del sistema de los sistemas operativos Unix . Ha llegado a ser ampliamente utilizado en otros sistemas operativos de computadoras , sistemas de archivos , lenguajes de programación y bases de datos .
El tiempo Unix se define actualmente 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 época Unix . [3] El tiempo en Unix normalmente se codifica como un número entero con signo .
La era Unix0 es exactamente la medianoche UTC del 1 de enero de 1970, y el tiempo Unix se incrementa en 1 por cada segundo no bisiesto después de esto. Por ejemplo, las 00:00:00 UTC del 1 de enero de 1971 se representan 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 bisiesto 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 Unix el tiempo consta exactamente de86 400 segundos.
El tiempo Unix a veces se denomina tiempo de época . Esto puede ser engañoso ya que la hora Unix no es el único sistema de tiempo basado en una época y la época de Unix no es la única época utilizada por otros sistemas de tiempo. [5]
El tiempo Unix se diferencia tanto del tiempo universal coordinado (UTC) como del tiempo atómico internacional (TAI) en su manejo de los segundos intercalares . UTC incluye segundos intercalares que se ajustan a la discrepancia entre la hora precisa, medida por relojes atómicos , y la hora solar , relacionada con la posición de la Tierra en relación con el sol. Tiempo Atómico Internacional (TAI), en el que cada día es exactamente86.400 segundos de duración, ignora la hora 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 tiempo Unix, cada día contiene exactamente86 400 segundos. Cada segundo intercalar utiliza la marca de tiempo de un segundo que lo precede o le sigue inmediatamente. [3]
En un día UTC normal, que tiene una duración de86 400 segundos, el número de tiempo de Unix cambia de manera continua durante 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 intercalar , el día UTC no es exactamente86 400 segundos de duración y el número de tiempo de 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 hasta el día siguiente durante el segundo intercalar y luego, al final del segundo intercalar, retrocede 1 (volviendo al inicio del día siguiente). Por ejemplo, esto es lo que sucedió en los sistemas POSIX.1 estrictamente conformes a finales de 1998:
Los números de tiempo de 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 al inicio del segundo intercalar (2016-12-31 23:59:60) o al final del mismo, un segundo después (2017-01-01 00:00:00 ). En el caso teórico de que se produzca un segundo intercalar negativo, no se produce ninguna ambigüedad, sino que existe 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 segundos intercalares positivos 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 de tiempo correspondientes. Esta es una técnica computacional común. Sin embargo, cuando ocurren 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 trata de tiempos Unix y, a menudo, es preferible utilizar una codificación de tiempo diferente que no sufra este problema.
Un número de hora Unix se convierte fácilmente en hora UTC tomando el cociente y el módulo del número de hora 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 le da un número de hora Unix que es ambiguo debido a un segundo intercalar positivo, este algoritmo lo interpreta como la hora 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 no válida. Si estas condiciones son significativas, es necesario consultar una tabla de segundos intercalares para detectarlas.
Por lo general, se implementa un reloj Unix estilo Mills con manejo de segundos intercalares no 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. [6] 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 intercalar, que indica sin ambigüedades si el salto ya se ha realizado. El cambio de 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 llega un poco tarde. Muy brevemente, el sistema muestra un número de tiempo nominalmente imposible, pero esto puede detectarse mediante el estado TIME_DEL y corregirse.
En este tipo de sistema, el número de tiempo Unix viola POSIX en ambos tipos de segundo intercalar. La recopilación de la variable de estado del segundo intercalar junto con el número de hora permite una decodificación inequívoca, por lo que se puede generar el número de hora 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 hipotético reloj compatible con 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 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 cronometraje 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 tiempo registrado 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), a diferencia de "UTC" ( aunque no todos los valores de hora UTC tienen una referencia única en sistemas que no cuentan segundos intercalares). [8]
Debido a que TAI no tiene segundos intercalares y cada día de TAI tiene exactamente 86400 segundos de duración, esta codificación es en realidad un recuento lineal puro de segundos transcurridos desde 1970-01-01T00:00:10 TAI. Esto facilita mucho la aritmética de intervalos de tiempo. 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 manera en que se deben consultar las tablas de zonas horarias para convertir hacia y desde la hora civil ; La base de datos de zonas horarias de la IANA incluye información de segundos intercalares, y el código de muestra disponible en 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 tropieza con problemas de definición antes del comienzo en 1972 de la forma actual de UTC (consulte la sección Bases de UTC a continuación).
Este sistema, a pesar de su parecido superficial, no es del tiempo de Unix. Codifica tiempos con valores que difieren en varios segundos de los valores de tiempo POSIX. Se propuso incluir 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, en ISO C , pero solo se aceptó la parte UTC en 2011. [9] Sin embargo, A existe en C++20. time.htai_clock
Un número de tiempo Unix se puede representar en cualquier forma capaz de representar números. En algunas aplicaciones, el número se representa simplemente textualmente como una cadena de dígitos decimales, lo que sólo plantea problemas adicionales triviales. Sin embargo, ciertas representaciones binarias de la época de 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. Un valor firmado 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 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 amplía los tiempos representables en aproximadamente 292 mil millones de años en ambas direcciones, lo que representa más de veinte veces la edad actual del universo .
Originalmente hubo cierta controversia sobre si Unix time_tdebería estar firmado o no. Si no se firma, su alcance en el futuro se duplicaría, posponiendo el desbordamiento de 32 bits (en 68 años). Sin embargo, entonces sería incapaz de representar tiempos anteriores a la época. El consenso está por time_tfirmarse, y ésta 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 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 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ífica para ello. POSIX requiere time_tque sea de tipo entero, pero no exige que esté firmado o sin firmar.
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 números enteros, siendo el primero a time_t(la parte integral del tiempo de Unix) y el segundo es 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 de 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 de UTC en la que no sólo había pasos de tiempo ocasionales, que eran de números no enteros, números de segundos, pero también 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 existía un cronometraje atómico generalizado ; en estas eras, 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 necesaria ]
La definición precisa de la hora Unix como codificación de UTC sólo no resulta 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 El número de días es lo único que importa para el tiempo 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. Las computadoras de esa época rara vez tenían relojes configurados con suficiente precisión como para proporcionar marcas de tiempo significativas de menos de un segundo en cualquier caso. La hora Unix no es una forma adecuada de representar horas anteriores a 1972 en aplicaciones que requieren una precisión inferior a un segundo; dichas solicitudes deben, al menos, definir qué forma de UT o GMT utilizan.
A partir de 2009 [actualizar]se baraja la posibilidad de acabar con el uso de los segundos intercalares en el tiempo civil. [12] Un medio probable para ejecutar este cambio es definir una nueva escala de tiempo, llamada Hora Internacional [ cita necesaria ] , que inicialmente coincida con UTC pero luego no tenga segundos intercalares, por lo que permanecerá en un desplazamiento constante de TAI. Si esto sucede, es probable que la hora 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 futuro de Unix no sea menos predecible de lo que ya es: si UTC simplemente no tuviera más segundos intercalares, el resultado sería el mismo.
Las primeras versiones de la hora Unix tenían un número 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 sólo podrían representar un rango de poco más de dos años y cuarto. La época a partir de la cual se cuenta 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 utilizaron como épocas durante el desarrollo inicial de Unix. Las primeras definiciones de hora de Unix también carecían de zonas horarias. [13] [14]
La época actual del 1 de enero de 1970 a las 00:00:00 UTC fue seleccionada arbitrariamente por los ingenieros de Unix porque se consideraba una fecha conveniente para trabajar. La precisión se cambió para contar en segundos para evitar desbordamientos a corto plazo. [1]
Cuando se escribió POSIX.1 , surgió la pregunta de cómo definir con precisión time_tlos segundos intercalares. El comité POSIX consideró si el tiempo Unix debería seguir siendo, como se esperaba, 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 ordenador de la época no estaban ajustados con suficiente precisión como para sentar un precedente en un sentido u otro.
El comité POSIX se dejó llevar por argumentos contra la complejidad de las funciones de la biblioteca, [ cita necesaria ] y definió firmemente la hora Unix de manera sencilla en términos de los elementos de la hora UTC. Esta definición era tan simple que ni siquiera abarcaba toda la regla del año bisiesto del calendario gregoriano, y haría del año 2100 un año bisiesto.
La edición de 2001 de POSIX.1 rectificó la regla defectuosa del año bisiesto 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 manera rutinaria con suficiente precisión para que esto tenga importancia, y lo más común es que se hayan 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 segundos intercalares. [ cita necesaria ]
La hora Unix se adopta ampliamente en la informática más allá de su aplicación original como la hora del sistema para Unix . El tiempo Unix está disponible en casi todas las API de programación de sistemas, incluidas las proporcionadas por sistemas operativos basados y no Unix . Casi todos los lenguajes de programación modernos proporcionan API para trabajar con tiempo Unix o convertirlos a otra estructura de datos. La hora Unix también se utiliza como 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 la hora Unix para todas las funciones de fecha y hora, y la hora Unix a veces se denomina 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 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 también se puede utilizar con marcas de tiempo de Unix. [19] Android usa la hora Unix junto con una zona horaria para la API de hora del sistema. [20]
Windows no usa el tiempo Unix para almacenar el tiempo internamente, pero sí lo usa 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 utiliza ampliamente en la programación de aplicaciones web, móviles y de escritorio. Java proporciona un objeto instantáneo que contiene una marca de tiempo Unix en segundos y nanosegundos. [22] Python proporciona una biblioteca de tiempo que utiliza el tiempo de Unix. [23] JavaScript proporciona una biblioteca de fechas que proporciona y almacena marcas de tiempo en milisegundos desde la época de Unix y se implementa en todos los navegadores web móviles y de escritorio modernos , 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 usa ampliamente en dispositivos Linux y Android, usan el tiempo Unix en nanosegundos para las marcas de tiempo de los archivos. [25] [26] Varios formatos de archivos pueden almacenar marcas de tiempo en tiempo Unix, incluidos RAR y tar . [27] [28] La hora Unix también se usa comúnmente para almacenar marcas de tiempo en bases de datos, incluso en MySQL y PostgreSQL . [29] [30]
Unix time fue diseñado para codificar fechas y horas del calendario de una manera compacta destinada a ser utilizada internamente por computadoras. No está diseñado para que los humanos lo lean fácilmente ni para almacenar valores que dependan de la zona horaria. También está limitado de forma predeterminada 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 programas. [31]
El tiempo Unix por diseño no requiere un tamaño específico para el almacenamiento, pero las implementaciones más comunes de tiempo Unix utilizan un entero con signo con el tamaño de palabra de la computadora subyacente. Como la mayoría de las computadoras modernas son de 32 o 64 bits , y una gran cantidad de programas todavía se escriben en modo de compatibilidad de 32 bits, esto significa que muchos programas que usan tiempo Unix usan campos enteros de 32 bits con signo. El valor máximo de un entero de 32 bits con signo es 2 31 -1 y el valor mínimo es -(2 31 ), 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 la hora Unix de 32 bits para las marcas de tiempo, puede ser necesario almacenar la hora 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 más allá del límite de 2038 regresarí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 la hora Unix, ya que el rango efectivo de fechas representables con la hora Unix almacenada 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 desde 1970. época. [31] : 60-61 [32]
El tiempo Unix no es el único estándar de 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 de 32 bits sin signo para los segundos y otro entero de 32 bits sin signo para las fracciones de segundo, que se repite cada 2 32 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 hay una serie de estándares de formato de hora que existen para ser legibles tanto por humanos como por computadoras, como ISO 8601 .
Los entusiastas de Unix tienen un historial de celebrar "fiestas time_t" (pronunciadas " fiestas de té del tiempo ") para celebrar valores significativos del número de tiempo de Unix. [38] [39] Estas son directamente análogas a las celebraciones de año nuevo que ocurren con el cambio de año en muchos calendarios. A medida que se ha extendido el uso del tiempo Unix, también lo ha hecho la práctica de celebrar sus hitos. Por lo general, lo que se celebra son los valores de tiempo que son números redondos en decimaltime_t , siguiendo la convención de Unix de ver valores en decimal. Entre algunos grupos también se celebran los números binarios redondos , como +2 30 que ocurrió a las 13:37:04 UTC del sábado 10 de enero de 2004. [ cita necesaria ]
Los eventos que estos celebran se describen típicamente como " N segundos desde la época Unix", pero esto es inexacto; Como se analizó 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.
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 utiliza la época Unix. El " programador-arqueólogo " responsable de encontrar y mantener códigos utilizables 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". [47]
El código tz y los datos admiten segundos intercalares a través de una configuración "correcta" opcional donde el reloj entero time_t interno de una computadora cuenta cada segundo TAI, a diferencia de la configuración "posix" predeterminada donde el reloj interno ignora los segundos intercalares.
Las dos configuraciones coinciden para las marcas de tiempo que comienzan con 1972-01-01 00:00:00 UTC (time_t 63 072 000) y divergen para las marcas de tiempo que comienzan con time_t 78 796 800, que corresponde al primer segundo intercalar 1972-06-30 23: 59:60 UTC en la configuración "correcta" y hasta 1972-07-01 00:00:00 UTC en la configuración "posix".
time
devuelve el tiempo transcurrido desde las 00:00:00 del 1 de enero de 1971, medido en sesentaésimas de segundo.
time
devuelve la hora desde las 00:00:00 del 1 de enero de 1972, medida en sexagésimas de segundo... La hora se almacena en 32 bits.
Esto garantiza una crisis cada 2,26 años.
El proyecto GNU C Library proporciona las bibliotecas principales para el sistema GNU y los sistemas GNU/Linux, así como para muchos otros sistemas que utilizan Linux como núcleo.
Esta marca de tiempo se representa como el número de nanosegundos desde el 1 de enero de 1970 a las 0:00 UTC, sin tener en cuenta los segundos intercalares.
La hora se almacena en formato Unix time_t si esta bandera [sic] está configurada y en formato Windows FILETIME en caso contrario
Atributos: año, mes, día, hora, minuto, segundo, microsegundo y tzinfo.
