Un timestamp Unix identifica un instante mediante su distancia al epoch, pero los dígitos no dicen si cuentan segundos o milisegundos. Una fecha escrita introduce otro riesgo: sin Z o desplazamiento explícito, la misma hora puede representar instantes distintos. Convertir bien exige mostrar unidad, zona y casos frontera.
Esta guía sigue medio segundo anterior al epoch con el conversor de timestamp Unix. El ejemplo fijo explica negativos, fracciones, UTC, desplazamientos y hora local, útil para caducidad de tokens, registros y APIs.
Identificar instante, unidad y zona
El epoch es 1970-01-01T00:00:00Z. Cero segundos y cero milisegundos son ese mismo instante. Lejos de cero, la unidad cambia todo: 1000 segundos son dieciséis minutos y cuarenta segundos; 1000 milisegundos son un segundo. La herramienta no adivina por longitud porque valores históricos cortos y futuros vuelven insegura esa heurística.
La salida ISO UTC describe el instante de forma estable. La salida local representa ese mismo punto con la zona detectada y la muestra. Que cambie la hora del reloj no significa que cambie el timestamp, sino el desplazamiento usado. Conviene almacenar y comparar el instante y localizarlo solo al presentarlo.
Un ejemplo antes de 1970
Usa exactamente:
1969-12-31T23:59:59.500Z
En milisegundos produce -500. En segundos enteros produce -1, porque se redondea hacia menos infinito. Truncar hacia cero daría 0 y colocaría erróneamente un instante anterior justo en el epoch. La diferencia aparece cuando la entrada contiene una fracción no representable en segundos enteros.
Comprueba también:
1970-01-01T01:00:00+01:00
El resultado es 0 en ambas unidades. El reloj marca 01:00, pero el desplazamiento +01:00 indica medianoche UTC. Ningún ejemplo depende de la zona local del equipo.
Convertir en ambas direcciones
Elige ISO a timestamp, pega el primer valor y selecciona milisegundos: exige -500. Cambia a segundos: exige -1. Copia cada resultado por separado y anota la unidad.
Pega el segundo valor y confirma cero. Cambia a timestamp a fecha, introduce -500 y selecciona milisegundos. UTC debe volver a 1969-12-31T23:59:59.500Z. La representación local puede mostrar otro día u hora, pero debe corresponder al mismo instante y enseñar su zona.
El botón «Ahora» captura el instante al pulsarlo; no es un reloj del servidor ni se actualiza durante SSR. Para depurar, conserva valor, unidad, ISO UTC y zona juntos. No pegues milisegundos en segundos solo para ver si la fecha parece razonable.
Por qué ISO estricto y floor importan
La conversión inversa acepta fecha y hora completas con Z o desplazamiento numérico. Rechaza 2026-09-17T10:00:00 porque no identifica un instante único. También valida el calendario antes de construir la fecha: 2026-02-30T00:00:00Z falla en vez de normalizarse silenciosamente a marzo.
ECMAScript representa el tiempo como milisegundos respecto del epoch y limita el rango de Date. La herramienta exige además enteros seguros, comprueba rango y limita la entrada a 100 caracteres. Los mensajes distinguen sintaxis, unidad, precisión y rango en vez de mostrar un «Invalid Date» genérico.
Floor asigna una fracción al segundo entero que la contiene. A 500 ms después del epoch, 0.5 baja a 0; a 500 ms antes, -0.5 baja a -1. Así se mantiene el orden correcto alrededor de cero.
Diagnosticar fechas incorrectas
Una fecha cerca de 1970 o exageradamente futura suele indicar unidad equivocada. Consulta el contrato del origen; no multipliques o dividas por mil hasta saberlo. Una misma API puede usar unidades distintas en campos diferentes.
Fecha inválida puede significar falta de zona, día imposible o sintaxis no admitida. Usa 2026-09-17T10:00:00Z o 2026-09-17T12:00:00+02:00. Una fecha sola o 17/09/2026 10:00 no define un instante.
Un entero inseguro o fuera de rango no debe redondearse hasta pasar. Conserva el texto y consulta al productor. Si la hora local sorprende, mira zona y UTC antes de tocar el valor. La entrada ISO admite segundos y de una a tres cifras fraccionarias; una precisión mayor debe decidirse fuera del conversor.
Aplicarlo a flujos reales
Para caducidad de tokens, compara unidades compatibles y documenta si el límite es inclusivo. Decodificar exp no verifica firma ni autorización. En logs, conserva UTC y timestamp original; añade la hora local solo como presentación. En bases de datos, elige una precisión acorde al origen.
Un desplazamiento relaciona con UTC en ese instante, pero no es una zona completa. +02:00 no significa necesariamente Europe/Madrid ni describe cambios futuros de horario. Para programar hora civil, almacena una zona IANA separada.
La conversión se realiza en el navegador. Aun así, no uses capturas de tokens o logs reales como ejemplo. Sustituye identificadores y payloads por datos sintéticos y registra solo los campos necesarios.
Límites del conversor
Convierte enteros en segundos o milisegundos elegidos y fechas ISO estrictas con Z o desplazamiento. No infiere unidad, interpreta fechas regionales, modela segundos intercalares, conserva precisión inferior al milisegundo ni obtiene una zona IANA de un offset. Los segundos descartan fracciones con floor, también en negativos.
El formato local depende del navegador y su base de zonas. Sirve para mostrar, no para probar una regla histórica. La conversión tampoco demuestra que el timestamp sea confiable, actual, firmado o el campo semántico correcto. Eso se valida en el protocolo de origen.
Tampoco se conservan nombres de zona en una cadena ISO con offset: dos lugares pueden compartir +01:00 en un instante y divergir más adelante. Para auditorías, guarda el valor original, su unidad y la representación UTC obtenida; si la zona de negocio importa, almacena su identificador IANA como dato separado. Esta separación evita convertir una preferencia visual del navegador en parte accidental del registro.
Al trabajar con fracciones, anota la precisión del sistema productor. Un servicio que emite microsegundos no puede representarse exactamente con esta interfaz de milisegundos. Decide antes si redondear, truncar o usar otra biblioteca y prueba valores a ambos lados de cero. Nunca presentes un resultado reducido como si conservara una precisión que ya se perdió.
Lista final de timestamp
Nombra el campo y la unidad documentada; conserva el texto original. Prueba cero, un valor conocido y el fixture negativo. Para ISO exige fecha real y Z u offset. Verifica UTC antes de local y registra la zona detectada.
Exige -500 ms y -1 s para 1969-12-31T23:59:59.500Z, cero para 1970-01-01T01:00:00+01:00 y rechazo de 2026-02-30T00:00:00Z. Copia cada valor con unidad y compara solo magnitudes expresadas igual.
Incluye también una prueba positiva contemporánea tomada de la documentación del sistema, no de una fecha que «parezca» correcta. Convierte en ambas direcciones y exige igualdad exacta de la forma UTC normalizada. Si el flujo usa expiraciones, prueba justo antes, en y después del límite. Si usa registros, ordena por el valor numérico original y confirma que la presentación local no altera ese orden.
Guarda el caso de prueba junto con la versión del productor y el contrato de unidad. Si otro equipo cambia segundos por milisegundos, esa revisión debe modificar explícitamente el campo o la documentación, no depender de una nueva inferencia del lector. En observabilidad, muestra la unidad en la etiqueta y ofrece UTC como referencia compartida.
Fuentes: ECMAScript: objetos Date, formato de fecha y hora ECMAScript y RFC 3339.