För att lösa ett specifikt tidszonsrelaterat fel på ett mjukvaruprojekt som jag jobbar med försöker jag replikera en ändring i systemet ” s klocka med timedatectl för att kontrollera mitt programbeteende.
Jag försöker uppnå det genom att köra
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 När jag gör det och kör timedatectl direkt efter får jag den förväntade följande tiden:
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 Tio sekunder efter detta, när minuten ändras (till xx:59), kommer den lokala och universella tidssorten ”omstart” till aktuell tid
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 Vad saknar jag här?
Min inställning är en Vagrant Ubuntu 18 VM (Linux vagrant 4.15.0-51 / vm box ”bento / ubuntu-18.04”).
Kommentarer
Svar
Detta kommer inte att förklara beteendet du ser, men det borde svara på frågan i titeln.
Istället för att ändra systemets tid kan du använda ett verktyg som faketime och TZ miljövariabel:
$ 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 Detta gör att du kan köra ditt program med sin egen tidszon, datum och tid utan att påverka resten av systemet.
Observera att när det är använder en $LD_PRELOAD hack för att injicera kod i applikationer, den fungerar inte för statiskt länkade körbara filer eller setuid / setgid körbara filer.