¿Segundos o milisegundos?
Un timestamp Unix cuenta el tiempo transcurrido desde la medianoche UTC del 1 de enero de 1970. El problema es que unos sistemas cuentan en segundos y otros en milisegundos.
- Segundos — comandos Unix, funciones de tiempo de PostgreSQL y MySQL, los campos
expeiatde un JWT, la mayoría de APIs REST - Milisegundos —
Date.now()de JavaScript,System.currentTimeMillis()de Java, muchas cadenas de recogida de logs
Si los confundes acabas en enero de 1970 (milisegundos leídos como segundos) o por el año 50000 (segundos leídos como milisegundos). Esta herramienta deduce la unidad por la magnitud y te dice cómo interpretó el número, así que revisa esa línea en cuanto una fecha parezca rara.
La trampa de la zona horaria
Un timestamp no tiene zona horaria. Es un único número que nombra un instante; la zona solo aparece cuando ese número se convierte en texto para una persona. El mismo valor se lee como las 16:00 en Madrid y las 07:00 en Ciudad de México.
Por eso un informe de error que dice “falló a las 3 de la tarde” viene sin la mitad de la información. Registra timestamps o cadenas ISO 8601 con desplazamiento, y arma la hora legible solo en el momento de mostrarla.
El problema de 2038
Guardado en un entero de 32 bits con signo, un timestamp se desborda el 19 de enero de 2038. En ese instante el valor da la vuelta a negativo y la fecha pasa a 1901. Los lenguajes y bases de datos actuales usan 64 bits, pero si mantienes firmware embebido antiguo o código C heredado, conviene mirar el ancho de ese campo.
Valores negativos y cero
Los negativos apuntan a fechas anteriores a 1970. Aparecen cuando se guardan así fechas antiguas como una fecha de nacimiento, y algunas bibliotecas los tratan mal.
Cero es la medianoche UTC del 1 de enero de 1970. Cuando aparece en datos reales casi nunca es una hora real: es un campo que nadie inicializó.