Las marcas de tiempo Unix, explicadas
Una marca de tiempo Unix es solo un conteo de segundos, y sin embargo causa un flujo constante de errores. Qué cuenta, cómo distinguir segundos de milisegundos de un vistazo, qué pasa con las zonas horarias y los segundos intercalares, y por qué importa 2038.
Abre casi cualquier archivo de registro, exportación de base de datos o respuesta de una API y encontrarás números como 1791288000 donde debería haber una fecha. Ese número es una marca de tiempo Unix, la forma más común en que las computadoras guardan un instante. Esta guía explica qué significa el número, cómo reconocer su unidad de un vistazo, dónde entran las zonas horarias y por qué importa el año 2038.
Qué significa el número
Una marca de tiempo Unix es el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, un instante llamado la época Unix. La elección de la fecha es histórica: era un número redondo cómodo cuando se escribía el sistema operativo Unix en los Bell Labs, hacia 1970.
Su atractivo es la sencillez. Un solo entero es fácil de guardar, ordenar y comparar, dos instantes se restan para obtener una duración en segundos, y el mismo número significa el mismo instante en todo el mundo. Algunos hitos ayudan a hacerse una idea de la escala:
| Marca de tiempo | Instante (UTC) |
|---|---|
0 | 1 de enero de 1970, 00:00:00 |
-1 | 31 de diciembre de 1969, 23:59:59 |
1000000000 | 9 de septiembre de 2001, 01:46:40 |
1234567890 | 13 de febrero de 2009, 23:31:30 |
1700000000 | 14 de noviembre de 2023, 22:13:20 |
2000000000 | 18 de mayo de 2033, 03:33:20 |
2147483647 | 19 de enero de 2038, 03:14:07 |
Se permiten números negativos, que cuentan hacia atrás, así que las fechas anteriores a 1970 también funcionan, siempre que el software que las lee lo espere.
¿Segundos, milisegundos o más?
La definición original usa segundos, pero muchos sistemas cuentan unidades más finas desde la misma época. Date.now() de JavaScript, System.currentTimeMillis() de Java y la mayoría de las API web usan milisegundos. Las bases de datos y las herramientas de trazado a veces usan microsegundos o nanosegundos.
Para las fechas de nuestra época, el número de dígitos delata la unidad:
- 10 dígitos: segundos (esto se cumple hasta el año 2286).
- 13 dígitos: milisegundos.
- 16 dígitos: microsegundos.
- 19 dígitos: nanosegundos.
Confundirlos es uno de los errores de fecha más comunes. Un valor en segundos leído como milisegundos cae en enero de 1970; un valor en milisegundos leído como segundos cae decenas de miles de años en el futuro. Si una fecha de tu aplicación aparece en 1970, un factor de 1000 que falta es lo primero que hay que revisar. Nuestro conversor de marcas de tiempo detecta la unidad por el número de dígitos, y puedes cambiarla.
Zonas horarias: la marca de tiempo no tiene ninguna
Una marca de tiempo identifica un instante, no la lectura de un reloj de pared. El valor 1791288000 es el mismo instante en Tokio, París y Nueva York; solo difiere la hora local. Convertirlo en una fecha legible siempre implica elegir una zona horaria, y la mayoría de los errores ocurren en ese paso.
La práctica habitual es guardar y enviar las marcas de tiempo en UTC y convertirlas a la hora local solo al mostrárselas a una persona. Cuando conviertes una fecha local de vuelta a una marca de tiempo, tienes que saber en qué zona horaria estaba esa fecha. «9 de marzo de 2025, 09:00» es una marca de tiempo distinta en Berlín que en Chicago, y alrededor de los cambios de horario una hora local puede incluso existir dos veces o no existir.
Los segundos intercalares se ignoran
La rotación de la Tierra es ligeramente irregular, así que el UTC oficial ha insertado de vez en cuando un segundo intercalar, 27 entre 1972 y 2016. El tiempo Unix hace como si no existieran: cada día dura exactamente 86 400 segundos. Durante un segundo intercalar, el reloj Unix repite un segundo o lo reparte.
Para casi cualquier propósito esto es una ventaja. Significa que la marca de tiempo de cualquier fecha se calcula con aritmética simple, y que restar dos marcas de tiempo da la diferencia en segundos de calendario. Solo las aplicaciones que necesitan medir intervalos físicos al segundo a través de un segundo intercalar, como algunos sistemas científicos, deben preocuparse. Los organismos internacionales de medición del tiempo han votado dejar de añadir segundos intercalares para 2035.
El problema del año 2038
Muchos sistemas antiguos guardan la marca de tiempo en un entero de 32 bits con signo. El valor más grande que puede contener es 2 147 483 647, que corresponde al 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el número se desborda y pasa al valor más negativo, que esos sistemas leen como el 13 de diciembre de 1901.
Es el mismo tipo de problema que el efecto 2000, y se está resolviendo de la misma manera: pasando a números más anchos. Una marca de tiempo de 64 bits con signo dura unos 292 000 millones de años. Los sistemas operativos, las bases de datos y los lenguajes modernos ya usan tiempo de 64 bits, pero los dispositivos embebidos, los formatos de archivo antiguos y algunas bases de datos con columnas de marca de tiempo de 32 bits necesitarán actualizarse antes de 2038. Si diseñas hoy un formato de archivo o una columna de base de datos, dale 64 bits.
Un conteo de segundos de 64 bits con signo dura unos 292 000 millones de años, muy fuera de esta escala.
Convertir a mano y en código
En la mayoría de los lenguajes, la conversión ocupa una línea. Algunos ejemplos:
// JavaScript: de segundos a Date, y de vuelta
new Date(1791288000 * 1000).toISOString(); // "2026-10-06T12:00:00.000Z"
Math.floor(Date.now() / 1000); // la marca de tiempo actual en segundos
# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1791288000, tz=timezone.utc)
-- PostgreSQL
SELECT to_timestamp(1791288000);Las hojas de cálculo cuentan días en lugar de segundos, desde su propia época. En Excel y Google Sheets, una marca de tiempo Unix en la celda A1 se convierte en fecha con =A1/86400+25569 (y luego dale a la celda formato de fecha), porque 25 569 es el número de días entre el 1 de enero de 1900 y el 1 de enero de 1970 en el calendario de Excel.
Para comprobaciones puntuales, el conversor de marcas de tiempo muestra la marca de tiempo actual en directo, convierte cualquier marca de tiempo en una fecha en la zona horaria que elijas (detectando la unidad por ti), hace el camino inverso desde una fecha y mide la diferencia entre dos fechas. Funciona en tu navegador, así que los valores que pegas se quedan en tu dispositivo.
Preguntas y respuestas
¿Por qué mi fecha muestra el 1 de enero de 1970?
El programa leyó un valor cero, o una marca de tiempo en segundos como milisegundos. Busca un campo vacío y una multiplicación o división por 1000 que falte.
¿Una marca de tiempo Unix está en UTC?
Cuenta desde un instante definido en UTC y describe el mismo instante en todas partes, así que en la práctica sí. Solo se convierte en hora local cuando la conviertes para mostrarla.
¿Dejará de funcionar mi computadora en 2038?
Los sistemas operativos actuales de computadoras y teléfonos usan tiempo de 64 bits y no se ven afectados. El riesgo está en los dispositivos embebidos antiguos, el software heredado y los formatos de datos que aún guardan marcas de tiempo de 32 bits.
¿Cómo obtengo la marca de tiempo Unix actual?
En una terminal de macOS o Linux, ejecuta date +%s. En JavaScript, usa Math.floor(Date.now() / 1000). El conversor de marcas de tiempo también la muestra en directo.
Herramientas de este artículo
Más del blog
ZIP, 7z o RAR: ¿qué formato de archivo comprimido es mejor?
Empaquetamos las mismas carpetas de fotos, videos, documentos y datos en ZIP, 7z y RAR y medimos el peso y la velocidad. El ganador depende casi por completo de lo que hay dentro.
CSV, Excel o JSON: ¿qué formato para tus datos?
Guardamos la misma tabla de 100 000 filas en CSV, en un libro de Excel y en JSON, y comparamos los pesos, la velocidad de lectura en código y lo que falla con las fechas, los ceros a la izquierda y los números largos.
Corrección de errores y tamaño del código QR: L, M, Q y H probados
Una corrección de errores más alta permite que un código QR resista daños, pero también lo hace más denso. Generamos códigos para cuatro tipos comunes de contenido en cada nivel y los tapamos poco a poco hasta que dejaron de leerse.