Herramientas de desarrollo · Conversor de marcas de tiempo Unix
¿Segundos o milisegundos? Diferenciar una época de 10 dígitos de una de 13 dígitos
· Cómo funciona
marcas de tiempo tiempo unix flujo de trabajo del desarrollador
La mayoría de los valores de época que encontramos hoy son de diez dígitos (segundos) o trece dígitos (milisegundos), y adivinar mal arroja una fecha de decenas de miles de años. Esta publicación explica la aritmética detrás del conteo de dígitos y por qué un convertidor debería indicar la unidad en lugar de inferirla.
1700000000 o 1700000000000? — el mismo instante escrito en dos sentidos, y el tablero que mostraba una fecha en el futuro lejano
Un valor de registro de 1700000000 y un valor de carga útil de 1700000000000 pueden describir el mismo instante. Trate el primero como milisegundos y su tablero caerá en enero de 1970; Trate el segundo como segundos y su fecha saltará miles de años hacia el futuro. Una marca de tiempo es solo un recuento más una unidad y un punto de partida, por lo que una columna de base de datos denominada create_at sin documentación ha omitido información esencial.
Por qué los recuentos de segundos actuales tienen diez dígitos: el milmillonésimo segundo en 2001, el rango de diez dígitos que llega hasta 2286, y qué significarían nueve dígitos
El tiempo Unix cuenta los segundos transcurridos desde el 1970-01-01 00:00:00 UTC según la convención POSIX habitual. El contador superó los mil millones en 2001; para las fechas positivas contemporáneas suele ser de diez dígitos decimales. Sigue siendo de diez dígitos hasta que alcanza los diez mil millones en 2286. Esta es una propiedad de la notación de base diez, no una regla incorporada en una cadena de fecha ISO. Los valores negativos anteriores a la época y las fechas muy alejadas del presente invalidan un simple atajo de recuento de dígitos.
Por qué los conteos de milisegundos tienen trece: un factor de mil, tres dígitos adicionales y de dónde provienen las convenciones de JavaScript y Java
JavaScript Date.getTime() convencionalmente cuenta milisegundos, multiplicando una marca de tiempo de segundos por 1000. Tres ceros hacen que un segundo actual de diez dígitos se convierta en un conteo de milisegundos de trece dígitos. Por ejemplo, 1.700.000.000 segundos se convierten en 1.700.000.000.000 milisegundos; ambos son 2023-11-14T22:13:20.000Z. Un convertidor que simplemente inserta separadores sin indicar la unidad supuesta puede convertir un número válido en una fecha plausible pero incorrecta.
Donde las conjeturas salen mal: valores pequeños cerca de la época, fechas anteriores a 2001 y fechas futuras en las que el recuento de dígitos deja de discriminar
La heurística falla cerca de 1970, cuando un valor de milisegundos puede ser corto, antes de 2001, cuando los segundos tienen menos de diez dígitos, o con contadores de microsegundos y nanosegundos. ToolAcre interpreta de forma predeterminada las magnitudes inferiores a 10¹¹ como segundos y los valores mayores como milisegundos, y etiqueta la unidad utilizada. Ese umbral es una suposición práctica, no un decodificador de formato inequívoco. Una marca de tiempo proporcionada por una API específica debe interpretarse utilizando la documentación de esa API incluso cuando su longitud sea inusual.
Ejemplo resuelto: tres valores de un registro: 1700000000, 1700000000000 y 1700000000000000, leídos en segundos, milisegundos y microsegundos
Tres números enteros de un registro ilustrativo muestran la trampa. Interprete 1700000000 como segundos y 1700000000000 como milisegundos: ambos se resuelven en 2023-11-14T22:13:20Z. Interprete 1700000000000000 como microsegundos y divídalo por un millón para obtener el mismo recuento de segundos. El convertidor ToolAcre acepta segundos o milisegundos, no un modo de microsegundos: pegar ese tercer número sin convertir primero su unidad no confirmará el instante deseado. Mantenga siempre juntos el campo sin formato y su unidad durante la depuración.
Por qué se debe indicar la unidad, no adivinarla: cómo el convertidor muestra la unidad que aplicó para que una suposición errónea sea visible en lugar de silenciosa.
Un servicio que envía marcas de tiempo debe nombrar la unidad en su esquema o utilizar texto ISO 8601 con un desplazamiento explícito. Si un campo heredado no está documentado, compare varios valores con otro tiempo de evento confiable antes de decidir; una sola fecha coincidentemente plausible es evidencia insuficiente. El convertidor muestra qué unidad aplicó, lo que le brinda la oportunidad de detectar un error de factor de 1000. Cambie la unidad explícitamente y compare en lugar de depender de una suposición automática como un contrato API a largo plazo.
Lo que esto no cubre: marcas de tiempo almacenadas como cadenas, texto ISO 8601 o fechas de serie de hojas de cálculo, que son problemas diferentes.
Este artículo no explica las fechas de serie de Excel, cadenas como 2026-09-28T10:15Z o el formato de zona horaria de las lecturas del reloj local. Esas son representaciones diferentes. Las marcas de tiempo de Unix se refieren a un instante; el mismo instante aparece como diferentes horas de reloj de pared en diferentes zonas. Las convenciones de segundos intercalares también merecen un tratamiento separado, y un contador firmado de 32 bits tiene un problema de desbordamiento en 2038 que es distinto de la cuestión de segundos versus milisegundos.
Conclusión: cuente los dígitos, luego confirme la unidad y cómo el convertidor de marca de tiempo de Unix lee segundos y milisegundos con la unidad etiquetada.
Cuente los dígitos como pista inicial, luego confirme la unidad indicada por el productor y al menos un evento conocido. El conversor de marcas de tiempo de Unix hace visible la suposición de segundos/milisegundos aplicada e imprime representaciones UTC y locales en su navegador. No permita que una fecha elegante anule la documentación contraria del sistema que produjo el valor.