Para resolver un error específico relacionado con la zona horaria en un proyecto de software en el que «estoy trabajando, estoy tratando de replicar un cambio en el sistema» s usando timedatectl para verificar el comportamiento de mi software.
Estoy tratando de lograrlo ejecutando
timedatectl set-timezone America/New_York timedatectl set-local-rtc 1 timedatectl set-ntp false timedatectl set-time "2017-03-12 01:58:50" && hwclock -w Cuando hago eso y ejecuto timedatectl inmediatamente después, obtengo el siguiente tiempo esperado:
Local time: Sun 2017-03-12 01:58:51 EST Universal time: Sun 2017-03-12 06:58:51 UTC RTC time: Sun 2017-03-12 01:58:51 Time zone: America/New_York (EST, -0500) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: yes Sin embargo, 10 segundos después de esto, cuando el minuto cambia (a xx:59), la hora local y universal se «reinicia» a la hora actual
Local time: Wed 2019-08-07 21:01:41 EDT Universal time: Thu 2019-08-08 01:01:41 UTC RTC time: Sun 2017-03-12 01:58:57 Time zone: America/New_York (EDT, -0400) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: yes ¿Qué me estoy perdiendo aquí?
Mi configuración es una VM Vagrant Ubuntu 18 (Linux vagrant 4.15.0-51 / vm box «bento / ubuntu-18.04»).
Comentarios
Responder
Esto no explica el comportamiento que está viendo, pero debería responder a la pregunta del título.
En lugar de cambiar la hora del sistema, puede usar una herramienta como faketime y la TZ variable de entorno:
$ date; faketime -f -15d date; TZ=America/New_York faketime -f -15d date Thu 8 Aug 10:21:13 CEST 2019 Wed 24 Jul 10:21:13 CEST 2019 Wed 24 Jul 04:21:13 EDT 2019 Esto le permitirá ejecutar su programa con su propia zona horaria, fecha y hora, sin afectar al resto del sistema.
Tenga en cuenta que como utiliza un $LD_PRELOAD hack para inyectar código en aplicaciones, no funcionará para ejecutables vinculados estáticamente o ejecutables setuid / setgid.