Desarrollo · 4 min de lectura ·
Marcas de tiempo Unix: ¿segundos o milisegundos?
El fallo de los 13 dígitos que llega a producción cada semana, y una regla muy sencilla para distinguir las dos unidades.
JavaScript habla en milisegundos. La mayoría de los backends, en segundos. Si los mezclas, tus fechas acaban en enero de 1970 o decenas de miles de años en el futuro.
Cuenta los dígitos
Una marca de tiempo actual en segundos tiene 10 dígitos (1790000000 es el 21 de septiembre de 2026). El mismo instante en milisegundos tiene 13 dígitos; en microsegundos, 16, y en nanosegundos, 19.
La regla
Si el valor absoluto es mayor que 10¹², son milisegundos; si no, trátalo como segundos. Funciona para cualquier marca en milisegundos posterior a septiembre de 2001 y cualquier marca en segundos anterior al año 33658.
const ms = Math.abs(n) > 1e12 ? n : n * 1000;Una marca de tiempo no tiene zona horaria
Una marca de tiempo Unix cuenta los segundos desde el 1 de enero de 1970 a las 00:00 UTC. El mismo número es el mismo instante en todo el mundo; solo cambia la forma de mostrarlo. Los errores aparecen cuando la hora local se convierte en marca de tiempo como si fuera UTC, lo que desplaza todas las fechas según tu diferencia horaria, a menudo una o dos horas, y otra vez con los cambios de horario de verano. Guarda y envía las marcas de tiempo en UTC, y conviértelas a hora local solo al mostrarlas a una persona.
Obtener la hora actual en lenguajes habituales
JavaScript Date.now() milisegundos
JavaScript Math.floor(Date.now() / 1000) segundos
Python time.time() segundos (con decimales)
Java System.currentTimeMillis() milisegundos
Go time.Now().Unix() segundos
PostgreSQL EXTRACT(EPOCH FROM now()) segundos
MySQL UNIX_TIMESTAMP() segundosFechas anteriores a 1970 y el año 2038
Las marcas de tiempo negativas son válidas: −86400 es el 31 de diciembre de 1969. Algunos sistemas antiguos y hojas de cálculo no las manejan, por eso las fechas de nacimiento y los datos históricos son una fuente habitual de errores. En el otro extremo, un entero con signo de 32 bits se agota en 2147483647, que corresponde a las 03:14:07 UTC del 19 de enero de 2038. Los sistemas que aún guardan marcas de tiempo en 32 bits volverán a 1901; el almacenamiento de 64 bits evita el problema durante miles de millones de años.
Segundos intercalares
El tiempo Unix ignora los segundos intercalares: cada día tiene exactamente 86.400 segundos. Eso mantiene la aritmética simple y, en casi todas las aplicaciones, la diferencia no importa. Solo los sistemas que necesitan intervalos precisos a través de un segundo intercalar, como algunos científicos o financieros, tienen que tenerlo en cuenta.
Lista rápida para depurar
- La fecha cae en enero de 1970: un valor en segundos se leyó como milisegundos.
- El año tiene cinco cifras: un valor en milisegundos se leyó como segundos.
- Todas las fechas se desvían el mismo número de horas: la hora local se trató como UTC, o al revés.
- Las fechas se desvían una hora durante parte del año: se ignoró un cambio de horario de verano.
- Las fechas saltan a 1901: un desbordamiento de 32 bits.
Elige la unidad de forma explícita
El conversor de marcas de tiempo de 4Dev no adivina: "Unix Timestamp" significa segundos y "Unix Timestamp (ms)" significa milisegundos, junto a variantes en microsegundos y nanosegundos: 33 formatos en total, incluidos ISO 8601, RFC 2822, SQL DATETIME y las fechas seriales de Excel.
ISO 8601 cuando la fecha la leen personas
Las marcas de tiempo son ideales para guardar y calcular, pero difíciles de leer. En registros, API y archivos que abren personas, ISO 8601, como 2026-09-21T14:30:00Z, no es ambiguo, se ordena bien como texto e indica la zona horaria de forma explícita. Convertir entre ambos es justo para lo que sirve el conversor de marcas de tiempo.