Afin de résoudre un bogue spécifique lié au fuseau horaire sur un projet logiciel sur lequel je « travaille, jessaye de répliquer un changement sur le système » s horloge en utilisant timedatectl pour vérifier le comportement de mon logiciel.
Jessaye dy parvenir en exécutant
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 Quand je fais cela et que je lance timedatectl juste après, jobtiens lheure suivante prévue:
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 Cependant, 10 secondes plus tard, lorsque la minute change (en xx:59), lheure locale et universelle est de type « redémarrer » à lheure actuelle
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 Que me manque-t-il ici?
Ma configuration est une VM Vagrant Ubuntu 18 (Linux vagrant 4.15.0-51 / vm box « bento / ubuntu-18.04 »).
Commentaires
Réponse
Cela nexpliquera pas le comportement que vous observez, mais cela devrait répondre à la question dans le titre.
Au lieu de changer lheure du système, vous pouvez utiliser un outil tel que faketime et la variable denvironnement TZ:
$ 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 Cela vous permettra dexécuter votre programme avec son propre fuseau horaire, date et heure, sans affecter le reste du système.
Notez que comme il utilise un $LD_PRELOAD hack pour injecter du code dans les applications, cela ne fonctionnera pas pour les exécutables liés statiquement ou les exécutables setuid / setgid.