Nanosegundos a fecha
Convierte nanosegundos en una fecha legible. Introduce la marca de tiempo en nanosegundos (p. ej. 1704067200000000000).
Una marca de tiempo en nanosegundos pierde en silencio sus tres últimos dígitos dentro de un número de JavaScript
Los números de JavaScript guardan enteros de forma exacta solo hasta 2⁵³ − 1. Una marca de tiempo actual en nanosegundos ronda 1,77 × 10¹⁸, que supera ese límite por un factor de 196. Introduce una y 1770000000123456789 vuelve como 1770000000123456800: sin error, sin aviso, simplemente tres dígitos sustituidos en silencio.
Cómo funciona
- Convierte marcas de tiempo en nanosegundos a fechas y al revés, conservando la parte por debajo del milisegundo.
- Señala el límite de precisión, porque este fallo es silencioso y no ruidoso.
- Se encarga de la conversión a milisegundos que la mayoría de bibliotecas de fechas exigen como entrada.
nanosegundos ÷ 1.000.000 = milisegundos nanosegundos ÷ 1.000.000.000 = segundos MAX_SAFE_INTEGER = 9.007.199.254.740.991 (2⁵³ − 1) en nanosegundos todo ese rango abarca solo unos 104 días en milisegundos abarca unos 285.000 años
Ejemplo resuelto
Qué abarca cada unidad de tiempo dentro del rango de enteros seguros y qué ocurre al superarlo.
- milisegundos: 2⁵³ abarca unos 285.000 años
- microsegundos: unos 285 años
- nanosegundos: unos 0,285 años, aproximadamente 104 días
- 1770000000123456789 asignado a un número
- se vuelve a leer como 1770000000123456800
Los tres últimos dígitos cambiaron y nada lo comunicó. Una marca de tiempo en nanosegundos necesita BigInt o una cadena; guardarla en un número corriente no es una molestia de redondeo, sino la garantía de que cualquier detalle por debajo del microsegundo es ficción.
Cómo leer el resultado
- Usa BigInt para la aritmética en nanosegundos y convierte a número solo después de dividir hasta milisegundos. La división debe ocurrir en el espacio de BigInt: convertir primero y dividir después ya ha destruido los dígitos que intentabas conservar.
- Las bases de datos y los formatos de transporte suelen llevar los nanosegundos como cadenas precisamente por esto. Parsear esa cadena a coma flotante para «dejarla limpia» es la forma más común de perder la precisión, y ocurre en la capa que nadie inspecciona.
- El propio Date de JavaScript se basa en milisegundos y no puede representar tiempos más finos. Convertir nanosegundos a Date descarta el resto por diseño, así que ahí la pérdida es esperable y no un fallo; lo sorprendente es solo cuando ocurre en silencio durante un cálculo.
- La precisión de nanosegundos rara vez es el requisito real. Ordenar registros, trazar y perfilar suelen necesitar orden monótono más que exactitud absoluta en nanosegundos, y un reloj monótono lo da sin el problema de representación.
Preguntas frecuentes
- ¿Por qué mi marca de tiempo cambió unos cientos de nanosegundos?
- Se guardó en un número de coma flotante incapaz de representarla. Por encima de 2⁵³ − 1 los enteros se redondean al valor representable más cercano, así que 1770000000123456789 pasa a ser 1770000000123456800. Nada lanza un error porque es comportamiento definido, no una avería.
- ¿Cómo deben guardarse las marcas de tiempo en nanosegundos?
- Como BigInt en JavaScript, como entero de 64 bits en la mayoría de los demás lenguajes, o como cadena al cruzar una frontera como JSON. Convierte a número solo cuando hayas dividido hasta milisegundos y ya no necesites los dígitos adicionales.