Herramientas de desarrollo · Convertidor de marca de tiempo Unix
El error fuera de 1000: cuando una fecha muestra enero 1970 o el año 56000
· Por qué es importante
marcas de tiempo depuración flujo de trabajo del desarrollador
Pasar segundos donde se esperan milisegundos (o al revés) es el error de marca de tiempo más común que existe. Esta publicación muestra cómo se ve en cada dirección, dónde se esconde entre idiomas y cómo detectarlo en segundos.
Todos los usuarios se unieron el 1 de enero 1970: la pantalla que revela el error y el backend que era perfectamente correcto
Una página de perfil que muestra todas las cuentas cerca de enero 1970 es un síntoma de escala fuerte. Es posible que el backend haya devuelto segundos de época correctos, mientras que el código del frontend los pasó directamente a un constructor de fecha que interpreta milisegundos. Un recuento actual se reduce entonces en un factor de mil en el eje del calendario.
No parchee la pantalla agregando un año constante o reemplazando la fecha. Capture el campo sin formato, su contrato API y la llamada exacta al constructor. ToolAcre le permite forzar ambas unidades, de modo que se pueda probar un valor sin cambiar los datos de producción. La lectura que coincide con otro evento conocido identifica el probable error de límite.
Los dos síntomas: segundos alimentados a un aterrizaje API de milisegundos en enero 1970, y milisegundos alimentados a un aterrizaje API de segundos decenas de miles de años después
Los segundos interpretados como milisegundos se acercan a la época porque mil millones de milisegundos es solo una pequeña fracción de un siglo. El error inverso expande un valor de un billón de milisegundos a un billón de segundos, a menudo fuera de los rangos de aplicación habituales. Ambos fallos conservan los dígitos aunque cambian su escala.
El artículo publicado de diez versus trece dígitos ya explica la heurística visual contemporánea y sus límites. En cambio, este artículo se centra en el diagnóstico y la prevención: selección explícita de unidades, evidencia de eventos independientes y una conversión en la interfaz donde la representación de un productor cumple con el contrato de un consumidor.
Debido a que ambas ramas son deterministas, el síntoma se puede reproducir con un solo elemento. Eso hace que la falta de coincidencia de unidades sea más fácil de probar que la desviación intermitente del reloj o el comportamiento de formato local.
Dónde suele estar el límite: JavaScript y Java en milisegundos, herramientas Unix, Python y la mayoría de las bases de datos en segundos, y la carga útil JSON entre ellos.
Este repositorio demuestra que JavaScript Date consume milisegundos y que ToolAcre multiplica segundos antes de construir uno. No establece los valores predeterminados de cada API de Java, Python, shell o base de datos mencionada en el libro. Esos contratos deben comprobarse en el lugar donde se utilizan.
Un número JSON no contiene metadatos de unidad. Nombrar un campo `created_at` transfiere la ambigüedad entre servicios; nombrarlo `created_at_s` o documentar una cadena ISO hace que el contrato sea revisable. El adaptador receptor debe convertir una vez a su representación interna en lugar de distribuir multiplicaciones entre las vistas.
Escriba la conversión junto a la definición de límite, no dentro de un asistente de visualización reutilizable. El adaptador conoce el contrato del productor; un formateador genérico debería recibir un instante ya normalizado.
El límite de la unidad es específico de API; este repositorio demuestra que JavaScript Date usa milisegundos
Un dispositivo débil como `0` no puede detectar el error porque cero segundos y cero milisegundos nombran la época. Los pequeños valores inventados también pueden parecer fechas 1970 plausibles. Un simulacro que arroja la misma escala esperada por su consumidor nunca ejerce un desajuste de integración real.
Elija un instante conocido distinto de cero y haga que las dos interpretaciones sean observablemente diferentes. Afirme el resultado ISO canónico en el límite, no simplemente que existe un objeto Fecha. Incluya un caso de milisegundos y un caso de segundos; Las propias pruebas de ToolAcre comparan 1,000,000 debajo de cada unidad exactamente por este motivo.
Los errores de unidad sobreviven siempre que las pruebas no logran distinguir las dos escalas
Considere `created_at: 1738578000`. Forzado en segundos, se convierte en `2025-02-03T10:20:00.000Z`; forzado en milisegundos, se convierte en `1970-01-21T02:56:18.000Z`. Un registro de implementación que se sabe que se creó en febrero 2025 resuelve la ambigüedad sin depender únicamente del recuento de dígitos.
Mantenga el JSON sin formato junto a ese evento conocido mientras repara el adaptador. Si el campo fuera `1738578000000`, la interpretación de milisegundos identificaría el mismo instante. Los dos valores nunca deben aceptarse indistintamente dentro de un esquema, aunque un convertidor pueda demostrar su equivalencia después de aplicar la escala correcta.
La fecha de implementación conocida es evidencia independiente. Sin él, elegir el resultado más plausible puede codificar las expectativas de un investigador en lugar de establecer lo que pretendía el productor.
Ejemplo resuelto: probar un valor creado_at en ambas unidades explícitas
La reparación duradera comienza en el límite: analiza la unidad de origen documentada, convierte exactamente una vez y expone un valor interno escrito o con un nombre claro. Las descripciones de esquemas, los ejemplos y los clientes generados deben conservar el sufijo o el formato de fecha y hora. Luego, un revisor puede detectar una multiplicación adicional antes del tiempo de ejecución.
Agregue un dispositivo de regresión con la escala real y una expectativa ISO fija. Evitar la autodetección en el código de la aplicación cuando el productor tiene un contrato; Las heurísticas sirven para investigar datos heredados inciertos. ToolAcre etiqueta su elección detectada precisamente para que la suposición no pueda hacerse pasar por metadatos garantizados.
Lo que esto no cubre: errores de zona horaria, que cambian una fecha en horas en lugar de décadas.
Un error de zona horaria normalmente cambia la visualización en horas y puede cruzar un día calendario. Un factor de error 1,000 cambia décadas o milenios. Mezclar los diagnósticos fomenta ajustes compensatorios en torno a un valor cuya escala ya es errónea. Verifique la unidad antes de inspeccionar el formato local.
De manera similar, un origen de época incorrecto puede seguir sin sentido tanto en segundos como en milisegundos. Si ninguna interpretación coincide con algún evento conocido, deje de alternar e investigue al productor. Un convertidor reduce las hipótesis; no prueba que cada número entero grande sea tiempo Unix.
Si el año es plausible pero la hora se desplaza constantemente, investigue la presentación de la zona. Mantener separadas estas escalas de síntomas acorta el camino desde la captura de pantalla hasta la causa raíz.
Conclusión: una unidad incorrecta es un siglo incorrecto y cómo la unidad indicada del conversor de marcas de tiempo de Unix le permite probar ambas lecturas en un momento
Una unidad incorrecta no son metadatos cosméticos: cambian en el instante. Trate las pantallas pesadas 1970 y los años inverosímilmente distantes como señales para inspeccionar la unión entre productor y consumidor. El valor, el contrato unitario y el hecho conocido forman una prueba de tres partes más fuerte que una fecha aparentemente razonable.
Utilice el convertidor para comparar lecturas explícitas y luego codifique la escala elegida en nombres, tipos y pruebas. El objetivo no es enseñar al software a adivinar de forma más inteligente. Es para eliminar las conjeturas de la ruta que crea fechas para los usuarios.
Una revisión del código puede entonces plantear una pregunta precisa en cada límite: ¿qué unidad entra y qué unidad sale? Esto es más confiable que reconocer un número particular de dígitos.