En resumen: un timestamp Unix es el número de segundos transcurridos desde la medianoche UTC del 1 de enero de 1970. Logs y APIs lo usan porque no tiene ambigüedad y es independiente de la zona horaria. Las dos cosas que despistan son distinguir los segundos de los milisegundos y recordar que el número en bruto siempre está en UTC hasta que lo conviertes a una zona local.
Al comparar entradas entre servidores, un simple entero es más fácil de razonar que una fecha formateada: sin zona horaria, sin configuración regional, sin ambigüedad del horario de verano. Pero esa misma crudeza es la razón por la que un timestamp perdido puede leerse mal.
Por qué los timestamps empiezan en 1970
La época Unix es la medianoche UTC del 1 de enero de 1970, elegida por los primeros desarrolladores de Unix en Bell Labs como punto de referencia simple y fijo. Cada timestamp Unix es solo el conteo de segundos desde ese momento, lo que convierte la aritmética — «¿cuánto tiempo entre estos dos eventos?» — en una simple resta.
¿Segundos o milisegundos?
Es el error más común al leer logs. Regla práctica: si el valor tiene más de 11 dígitos (mayor que unos 10¹¹), casi seguro está en milisegundos. Un timestamp actual en segundos ronda los 1.700 millones (diez dígitos); el mismo instante en milisegundos ronda los 1,7 billones (trece dígitos). Pasa un valor en milisegundos a un analizador de segundos y acabarás decenas de miles de años en el futuro.
El timestamp siempre está en UTC
Un timestamp Unix codifica un instante absoluto, no una hora local de reloj. Para mostrarlo a un humano aplicas una zona horaria: el mismo número es «14:30 en Londres» y «09:30 en Nueva York». Convertir en ambos sentidos de forma limpia significa ser explícito con la zona: un buen convertidor usa la base estándar de zonas IANA y la API Intl.DateTimeFormat para que el desfase (incluido el horario de verano) sea correcto para esa fecha.
ISO 8601 para todo lo que almacenes o compartas
Cuando un timestamp debe ser legible por humanos y a la vez seguro para la máquina, usa ISO 8601: 2024-03-15T14:30:00.000Z. La T separa fecha y hora y la Z indica UTC. Se ordena correctamente como texto plano y elimina la duda segundos-vs-milisegundos para quien lo lea después.
La nota sobre 2038
Los sistemas que almacenan el timestamp como entero con signo de 32 bits se desbordan el 19 de enero de 2038. La mayoría de las plataformas modernas ha pasado al tiempo de 64 bits, pero conviene saberlo ante un sistema antiguo o una columna de base de datos de ancho fijo.
Un flujo práctico
- Copia el valor en bruto de tu log o de la respuesta de la API.
- Pégalo en el Convertidor de Timestamp, que detecta automáticamente segundos vs milisegundos y muestra la fecha en la zona elegida.
- Convierte ambos eventos que comparas a la misma zona (o mantén los dos en UTC) antes de restar.
- Almacena o comparte el resultado como ISO 8601 para no reintroducir ambigüedad. Combínalo con el Contador de Caracteres si estás limpiando un extracto de log para un ticket.
Errores comunes que evitar
- Mezclar segundos y milisegundos en la misma comparación.
- Suponer que un timestamp en bruto ya está en hora local.
- Comparar dos eventos representados en zonas distintas.
- Usar campos de tiempo de 32 bits de ancho fijo que no sobreviven a 2038.