Chrono MockHaz que el reloj de una app corra más rápido
Una prueba de 30 días tarda 30 días en caducar, a menos que puedas mover el tiempo. El consejo habitual es adelantar el reloj del sistema, lo que exige permisos de administrador y arrastra consigo a todos los demás programas del equipo. Esto mueve un solo proceso.
Cuánto de rápido
Elige un multiplicador entero. El reloj de la aplicación avanza esas veces más rápido que el real, a partir del momento en que empieza la sesión.
| Multiplicador | Un minuto real se convierte en | Útil para |
|---|---|---|
x60 | una hora | tareas por hora, tiempos de espera de sesión, vida útil de tokens |
x1440 | un día | cambios diarios, una prueba de 30 días en media hora |
x43200 | una prueba de 30 días | ver terminar toda la prueba mientras lees esto |
x525600 | un año | renovaciones anuales, caducidad de certificados |
x1000000 | unos 1,9 años | el tope |
# Empezar en la hora real actual y correr un día por minuto chrono run "C:\apps\test.exe" --mode x1440 # Empezar en una fecha elegida y acelerar desde ahí chrono run "C:\apps\test.exe" --at 2027-12-01T09:00:00 --mode x1440 # Mantener el reloj completamente quieto en su lugar chrono run "C:\apps\test.exe" --mode frozen
Lo que pilla a la gente: hay dos relojes
Acelerar el reloj de pared - lo que devuelven DateTime.Now y sus
equivalentes - no acelera por sí solo una cuenta atrás. Son dos preguntas
distintas que una aplicación puede hacer al sistema operativo, y mucho software mide «treinta
días» con la segunda y no con la primera.
Por eso el eje de duraciones - contadores de ticks, suspensiones, esperas y temporizadores - es un interruptor aparte:
--scale-durationpasa también los contadores de ticks, las pausas y los temporizadores al reloj de la sesión, mientras que las esperas sobre objetos se cuentan y conservan su duración real. Sin él,x1440acelera el calendario mientras un temporizador de cinco segundos sigue durando cinco segundos reales - solo un temporizador fijado para una fecha y hora sigue el reloj de la sesión en cada sesión.--scale-qpcescala además el contador de alta resolución. Ahí es donde Python 3.13+monotonic, .NETStopwatchy JavananoTimeleen el tiempo transcurrido, y está desactivado por defecto porque escalarlo desestabilizó el renderizado en las pruebas.
Si el multiplicador parece no hacer nada con una cuenta atrás, casi siempre es por esto.
# Una app de temporizador: acelerar el calendario Y las cuentas atrás chrono run "C:\apps\Timer.exe" --mode x60 --scale-duration # Una app Python o .NET que mide el tiempo transcurrido con el contador de alta resolución chrono run "C:\apps\Job.exe" --mode x60 --scale-duration --scale-qpc
Cambiar la velocidad sin reiniciar
El multiplicador puede cambiar en plena sesión, y el reloj se reancla en lugar de saltar, así que nunca retrocede cuando baja la velocidad. También puedes hacer saltar el reloj sin más - hacia delante, o hacia atrás como lo hace un portátil al resincronizarse con un servidor de hora, que es el caso que rompe todo lo que mide tiempo transcurrido sin una protección.
# Correr a x60 y pasar a x1440 a los dos segundos chrono run "C:\apps\test.exe" --mode x60 --set-after 2:1440 # Correr y, a los cinco segundos, saltar el reloj a un momento elegido chrono run "C:\apps\test.exe" --jump-after 5:2028-01-01T00:00:00
Lo que no hará
- No toca el reloj del sistema. Ese es el objetivo, no una limitación - pero significa que todo lo que lea la hora de un servidor, una base de datos u otra máquina no se ve afectado, y la auditoría te lo dice cuando ocurre.
- Un salto cambia lo que ve la aplicación, no cuándo se despierta. Las pausas y los temporizadores ya entregados al kernel conservan la duración que recibieron al fijarse. La mayoría de las aplicaciones consultan el reloj, así que los saltos funcionan en la práctica - aunque no en todas.
- No ralentiza el tiempo. Los multiplicadores son números enteros de uno en adelante, más un reloj congelado en cero.
Si algo de esto llegó a tu aplicación no es algo que deba darse por supuesto. La sesión lo dice →