¿Qué es una Marca de Tiempo Unix?

Una marca de tiempo Unix es un único número: la cantidad de segundos transcurridos desde la época Unix, definida como las 00:00:00 UTC del 1 de enero de 1970. Eso es todo. Sin zona horaria, sin cadena de fecha, sin nombres de meses — solo un entero que aumenta una unidad por segundo.

Dado que la época es fija y universal, una marca de tiempo como 1700000000 significa el mismo instante exacto en cualquier lugar de la Tierra. Un servidor en Tokio y un portátil en Chicago coincidirán en que se refiere al 14 de noviembre de 2023 a las 22:13:20 UTC. La visualización local difiere según la zona horaria, pero el número subyacente nunca cambia.

Una simplificación deliberada: el tiempo Unix ignora los segundos intercalares. Asume que cada día tiene exactamente 86,400 segundos, lo cual no es del todo cierto en la realidad astronómica, pero mantiene la aritmética limpia. Más sobre esto a continuación.

Por Qué los Ingenieros las Aman

Las marcas de tiempo están en todas partes en el software — tiempos de modificación de archivos, registros de bases de datos, respuestas de API, campos de caducidad de JWT, líneas de registro — y por buenas razones:

• Son un único valor. Un solo entero almacena una fecha y hora completas. Sin análisis, sin ambigüedad sobre MM/DD versus DD/MM.
• Son independientes de la zona horaria. El número siempre es UTC. Conviertes a la hora local solo cuando se lo muestras a un humano.
• Se comparan y ordenan de forma trivial. ¿Qué evento ocurrió primero? El entero más pequeño. ¿Duración entre dos eventos? Réstalos; la respuesta está en segundos.
• Se almacenan de forma compacta. Un solo entero de 4 u 8 bytes frente a una cadena formateada.

Por eso tanta infraestructura habla en segundos de época internamente, incluso cuando la interfaz te muestra un amigable 2026-07-23. Si quieres moverte entre las dos representaciones, un Conversor de marca de tiempo Unix hace la traducción en ambas direcciones.

Leyendo Una: Un Ejemplo Práctico

Toma la marca de tiempo 1000000000 — una famosa, porque se desbordó en televisión en vivo entre los entusiastas de Unix.

Para leerla a mano, divides los segundos en unidades más grandes. Aproximadamente, 1,000,000,000 segundos son unos 31.7 años (un año es ~31,556,952 segundos). Suma eso a la época de 1970 y llegas a 2001. El momento preciso es 09 de septiembre de 2001, 01:46:40 UTC.

Rara vez haces esta aritmética manualmente — cada lenguaje tiene una función incorporada. En Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

El punto clave: la conversión está siempre anclada a UTC. La función convierte un recuento bruto de segundos en una fecha de calendario avanzando desde la época. Si quieres la hora local en su lugar, aplicas un desplazamiento de zona horaria después de la conversión a UTC — la marca de tiempo en sí no lleva información de zona.

El Problema del Año 2038

Aquí es donde la historia se vuelve interesante — y donde muchos sistemas que por lo demás están bien construidos tienen un reloj que hace tictac en su interior.

Durante décadas, el tipo estándar de C utilizado para almacenar el tiempo Unix, time_t, era comúnmente un entero de 32 bits con signo. Un entero de 32 bits con signo puede representar valores desde −2,147,483,648 hasta 2,147,483,647. Ese límite superior es el problema.

Contando segundos desde la época de 1970, el valor 2,147,483,647 se alcanza a las 03:14:07 UTC del 19 de enero de 2038. Un segundo después, el contador necesita convertirse en 2,147,483,648 — pero ese número no cabe en un entero de 32 bits con signo. En lugar de continuar hacia arriba, los bits se desbordan y envuelven al valor más negativo, −2,147,483,648.

Una marca de tiempo negativa se interpreta como un momento anterior a la época. Así que el reloj no solo se detiene — salta hacia atrás hasta el 13 de diciembre de 1901. Cualquier sistema que confiara en su time_t de 32 bits de repente cree que está a principios del siglo XX.

Esto a menudo se llama el error Y2K38 o el Error del Milenio Unix, y estructuralmente es el mismo tipo de desbordamiento de ancho fijo que impulsó el susto del Año 2000 — solo que más lejano y arraigado en los límites de los enteros binarios en lugar de años de dos dígitos.

Dónde Afecta Realmente

Los ordenadores y servidores modernos de 64 bits se corrigieron en gran medida hace años. El riesgo se concentra en lugares que son difíciles de actualizar:

• Sistemas embebidos e industriales. Enrutadores, controladores, dispositivos médicos, ECUs automotrices y hardware IoT que se envió con time_t de 32 bits y puede funcionar sin ser tocado durante 20+ años. Muchos dispositivos desplegados hoy seguirán en servicio en 2038.
• Código C heredado. Aplicaciones compiladas contra una definición antigua de time_t, especialmente donde el tipo se introdujo en formatos de disco o protocolos de red.
• Bases de datos y sistemas de archivos antiguos. Formatos de almacenamiento que empaquetaban marcas de tiempo en campos de 32 bits. Algunos sistemas antiguos ya muestran síntomas al manejar fechas lejanas futuras — piensa en una hipoteca a 20 años o una caducidad de certificado que llegue más allá de 2038.

El modo de fallo no siempre es un bloqueo dramático. A veces es una fecha sutilmente calculada incorrectamente: un token caducado que se lee como válido, un orden de clasificación que se invierte, un trabajo programado que se ejecuta en 1901.

La Solución: Tiempo de 64 Bits

El remedio es sencillo en principio — ampliar time_t a 64 bits. Un entero de 64 bits con signo puede contar segundos mucho más allá de cualquier horizonte práctico: el punto de desbordamiento se sitúa aproximadamente 292 mil millones de años en el futuro, cómodamente más allá de la vida esperada del Sol.

La mayoría de los sistemas operativos actuales ya han hecho este movimiento. Linux de 64 bits usa un time_t de 64 bits; incluso Linux de 32 bits obtuvo soporte de tiempo de 64 bits en el kernel y glibc en los últimos años. La parte difícil no es la corrección en sí — es encontrar y reconstruir cada último fragmento de firmware, cada formato almacenado y cada binario de terceros que aún asume 32 bits. Ese trabajo de auditoría es el verdadero proyecto de 2038.

Cómo Encajan los Segundos Intercalares

El tiempo astronómico y el tiempo atómico se desvían ligeramente, por lo que el UTC oficial ocasionalmente inserta un segundo intercalar para mantener los relojes alineados con la rotación de la Tierra. El tiempo Unix, por diseño, finge que estos no existen — codifica 86,400 segundos por día.

Cuando ocurre un segundo intercalar, los sistemas típicamente lo "extienden" — repartiendo el segundo extra a lo largo de una ventana (Google popularizó una extensión de 24 horas) para que ningún reloj tenga que mostrar el imposible 23:59:60. La consecuencia: las marcas de tiempo Unix se mantienen suaves y monótonas, a costa de estar una fracción diminuta de segundo fuera del UTC estricto durante una extensión. Para prácticamente todo el software, esta es exactamente la compensación que deseas. El desbordamiento de 2038 es un problema de ancho de entero; los segundos intercalares son una peculiaridad de definición separada y mucho más pequeña — no los confundas.

Conclusiones Clave

• Una marca de tiempo Unix son segundos desde las 00:00:00 UTC del 1 de enero de 1970, ignorando los segundos intercalares.
• Es un único entero independiente de la zona horaria — fácil de almacenar, comparar y ordenar.
• La conversión siempre es relativa a UTC; la hora local se aplica después.
• El time_t de 32 bits con signo se desborda a las 03:14:07 UTC del 19 de enero de 2038, envolviéndose a un valor negativo y saltando a 1901.
• La solución es time_t de 64 bits; el esfuerzo es auditar sistemas embebidos y heredados.

¿Quieres verlo en acción? Pega cualquier valor de época en el Conversor de marca de tiempo Unix para leerlo como una fecha humana — o ve al revés y convierte una fecha en su marca de tiempo.

Preguntas Frecuentes

¿Una marca de tiempo Unix está en segundos o milisegundos?

El tiempo Unix clásico está en segundos. Sin embargo, JavaScript y muchas APIs web usan milisegundos desde la época, por lo que un valor como 1700000000000 es 1,000× más grande. Una pista rápida: una marca de tiempo basada en segundos para una fecha reciente tiene 10 dígitos; una en milisegundos tiene 13. En caso de duda, verifica la magnitud antes de convertir.

¿El problema del año 2038 bloqueará mi teléfono o portátil?

Casi con toda seguridad no. Los sistemas operativos modernos de 64 bits ya usan un time_t de 64 bits, lo que empuja el desbordamiento a miles de millones de años. La exposición real está en dispositivos embebidos de larga duración y software antiguo que aún depende del tiempo de 32 bits y puede que no se actualice antes de 2038.

¿Puede una marca de tiempo Unix ser negativa?

Sí. Los valores negativos representan instantes anteriores a la época de 1970 — por ejemplo, -1 es el 31 de diciembre de 1969, 23:59:59 UTC. Esto es exactamente lo que produce un desbordamiento de 32 bits en 2038, por lo que el reloj parece saltar de nuevo a 1901.

¿Por qué el tiempo Unix ignora los segundos intercalares?

Para mantener las matemáticas simples y predecibles. Tratar cada día como exactamente 86,400 segundos significa que las duraciones son solo una resta, y las marcas de tiempo se mantienen monótonas. La pequeña discrepancia con el UTC astronómico se maneja "extendiendo" el segundo intercalar, lo que casi todas las aplicaciones prefieren a lidiar con un caso límite de 23:59:60.

¿Cómo convierto una marca de tiempo sin escribir código?

Usa una herramienta en línea. El Conversor de marca de tiempo Unix acepta un valor de época y muestra la fecha y hora UTC y local coincidentes al instante, y también convierte fechas de calendario de vuelta a marcas de tiempo.