staging.inyokaproject.org

Hallo Experten!

Ich möchte automatisiert, immer kurz vor den Zeitumstellungen, eine Aktion ausführen. Gibt es eine Möglichkeit auf "letzter Sonntag im März" bzw. "letzter Sonntag im Oktober" zu reagieren? Der Rechner macht das ja bereits, auf Basis von tzdata. Kann man das Signal (Tag der Zeitumstellung) irgendwie abgreifen?

Hintergrund: Eine Messwert-Datenbank fordert Zeitstempel in Lokalzeit und rechnet diese selbst in UTC um. Das Messgerät, das die Daten erfasst, kennt aber keine Sommer-/Winterzeit Umstellung, so dass dann "falsche" Zeitstempel geliefert werden. Deshalb ist ein Neustart der Messdatenerfassung nötig, weil dabei die /neue/ Lokalzeit vom PC auf das Messgerät übertragen wird. Ich habe das vorläufig mit einem Skript bewerkstelligt, das um 1:59 Uhr die Messungen stoppt und nach zwei Minuten wieder startet. Weil das Datum der Umstellung aber nicht fix ist, muss ich dieses Skript jeweils am Vortag manuell starten. Dies möchte ich gerne automatisieren.

Schön wäre, wenn es z.B. einen Crontab Eintrag für "letzter Sonntag im ..." und einer Uhrzeit gäbe. Ein Signal, das genau bei der Zeitumstellung auslöst, wäre nicht optimal, weil dann der eigentliche Vorgang ein paar Millisekunden /nach/ der Zeitumstellung starten würde und damit in der Log-Datei bereits ein falscher Zeitstempel gelandet ist, was ich gerne vermeiden würde.

Gibt es da was?

Grüße!

Einfach jeden Sonntag im März ein Script starten, und in dem Script prüfst Du, ob der Tag im Monat > (31 - 7) ist.

Ok, na klar! Monat und Wochentag kann ich in der Crontab ja benennen. Das wäre schon mal eine Möglichkeit!

Danke!

Manchmal braucht man einen kleinen Schupps, damit der Groschen fällt. Natürlich kann ich gleich im "Messdaten-Erfassungs-Skript" fortlaufend auf den Monat (3 oder 10), den Sonntag und den Tag >(31-7) prüfen. Dann habe ich ja schon alles!

Nochmals Danke!

Ist zwar etwas zu spät, aber kann das nicht so angepasst werden, dass einfach alles in UTC läuft (die Zeitzone des Rechners müsste man ja auf UTC umstellen können)? Dann kann man sich den Zirkus mit zusätzlichen Skripten und Restarts komplett sparen.

Mit at könnte man auch Befehle zu definierten Zeiten ausführen lassen - mit der Holzhammermethode wäre das ein einmaliger Aufruf für alle in der zoneinfo-Datei definierten Zeitpunkte (aktuell bis 2038):

1
2
3

while IFS='\n' read -r dst_change; do
    echo "/script/to/call" | at $(date -d "$dst_change" +"%H:%M %d.%m.%Y")
done < <(zdump -v /usr/share/zoneinfo/Europe/Berlin | grep ":59" | cut -d' ' -f 11-15)

Und wenn man den at-Spooler komplett aufräumen will:

atq | sort -n | cut -f1 | xargs atrm 

Das habe ich auch immer so gehalten. Nur muss ich in diesem Projekt diese Datenbank beliefern, die völlig unflexibel eine Umrechnung in UTC machen will und dafür unumstößlich von Zeitstempeln in Lokalzeit ausgeht. Würde ich UTC liefern, würde falsch umgerechnet werden.

maplecut schrieb:

Das habe ich auch immer so gehalten. Nur muss ich in diesem Projekt diese Datenbank beliefern, die völlig unflexibel eine Umrechnung in UTC machen will und dafür unumstößlich von Zeitstempeln in Lokalzeit ausgeht. Würde ich UTC liefern, würde falsch umgerechnet werden.

Ist das so (schlecht) umgesetzt, dass die Datenbank nicht damit zurecht kommt, wenn die Lokalzeit auf UTC gesetzt ist? Oder läuft die DB auf einem Rechner, wo das keine Option ist?

Sonst könnte man das Messgerät auch in UTC laufen lassen und daraus eine eindeutige Lokalzeit errechnen, die man dann an die DB schickt.

Ja, leider.

Weil du so genau fragst, nun etwas detailierter:

Ich hatte die Sache etwas vereinfacht dargestellt, um den Text nicht unnötig aufzublähen. In Wirklichkeit ist der Problemverursacher ein Frontend zur Monitoring-Auswertung, das auch lokal auf den jeweiligen Messrechnern läuft und von dort aus den Datenimport in eine SQL-Datenbank vornimmt. Damit Ereignisse, die weltweit jeweils vor Ort erfasst werden, zeitlich richtig zueinander abgebildet werden, wollten die Entwickler wohl sicherstellen, dass in der Datenbank immer UTC verwendet wird, und rechnen deshalb beim Import ungefragt um. Das ist hartkodiert und nicht veränderbar.

Messgerät mit UTC laufen lassen und vor dem Datenimport in Lokalzeit umrechnen, ist allerdings auch nicht schlecht!

Als Cron Command:

59 1 25-31 3,10 * [ "`date +%w`" -eq 0 ] && ...

Dies startet Cron an den letzten 7 Tagen im Monat März und Oktober. Der Test dahinter checkt dann ob es ein Sonntag ist. Das ist nötig, da day of month und day of week leider bei cron OR verknüpft sind.

Danke für den Hinweis mit der OR Verknüpfung! An der Stelle wäre ich bestimmt auf die Nase gefallen.