Zeitzone (TZ)

Bitte beachten Sie, dass "Zeitzone" (in Großbuchstaben) und "Zeitzone" nicht dasselbe sind. Wenn wir uns auf das Automic Automation-Objekt beziehen, verwenden wir "Zeitzone" (in Großbuchstaben), wenn wir uns auf die geografische Region mit derselben Standardzeit beziehen, verwenden wir dagegen "Zeitzone" (Kleinbuchstaben).

Wenn Programme miteinander kommunizieren, Aufgaben aktiviert, Bedingungen ausgewertet oder Daten gespeichert werden, spielen bei diesen und vielen anderen Prozessen die Zeitdefinitionen eine wichtige Rolle. Wird ein Automation Engine-System weltweit über mehrere Zeitzonen hinweg eingesetzt, gewinnen diese Definitionen für eine korrekte Ausführung miteinander vernetzter Aufgaben noch zusätzlich an Bedeutung. Alle Automic Automation-Komponenten nutzen den UTC-Standard. Dies ist auch die Standardzeit, die einem Objekt dessen Erstellung zugewiesen wird, es sei denn, Sie weisen ihm ein Zeitzonenobjekt zu. Die Standardzeitzone wird im Mandanten 0 definiert und steht systemweit zur Verfügung. Als Systemadministrator können Sie weitere Zeitzonenobjekte entweder im Mandanten 0 oder in den individuellen Mandanten hinzufügen. Als Entwickler und Objektdesigner ordnen Sie den von Ihnen erstellten Objekten die verfügbaren Zeitzonenobjekte zu.

Hinweis: Bei einer Neuinstallation von Automic Automation enthält der Ordner TEMPLATES in Client 0 verschiedene Zeitzonenobjekte. Wie bei allen anderen Objekten in diesem Ordner sind dies keine wirklich verwendbaren Objekte, sondern dienen lediglich als Vorlagen, die Administratoren beim Erstellen anderer Zeitzonenobjekte helfen. Die Zeitzonenobjekte, die Systemadministratoren in Client 0 erstellen, sind auf allen Clients verfügbar. Zeitzonenobjekte, die in einem bestimmten Client erstellt wurden, sind nur auf diesem Client verfügbar.

Zeitzonenobjekte (TZ) sind für Folgendes zuständig:

• Umwandlung von UTC in die Ortszeit, die in der Benutzerschnittstelle angezeigt und in Aufgaben, Script-Elementen usw. verwendet werden kann.
• Umwandlung der Zeit, in der ein Arbeitsschritt ausgeführt wurde, in die interne UTC-Zeit.
• Berechnung von Zeitänderungen aufgrund des Wechsels auf Sommer- oder Winterzeit. Dies ist äußerst wichtig, da UTC den Wechsel auf die Sommerzeit nicht berücksichtigt.

• CET (Central European Time)
• CST (Central Standard Time)
• EST (Eastern Standard Time)
• GMT (Greenwich Mean Time)
• MST (Mountain Standard Time)
• PST (Pacific Standard Time)
• SYD
• TZ

Diese Seite beinhaltet Folgendes:

Eine Definition eines Zeitzonen-Objekts besteht aus den folgenden Seiten:

• Standardseiten, die unabhängig von dem von Ihnen definierten Objekttyp zu jeder Zeit verfügbar sind:
  • Definieren der Seite "Allgemein"
  • Definieren der Seite "Dokumentation"
• Die hier beschriebene, objektspezifische Seite.

Wichtig! Im Abschnitt Sommerzeiteinstellungen geben Sie an, ob das Zeitzonenobjekt die Sommerzeitverschiebung berücksichtigt. Wenn sich Client von Ihnen in einem Land befinden, in dem diese Zeitumstellung stattfindet, und Sie diese Option NICHT aktivieren, wird bei Aufgaben, die zum Zeitpunkt der Zeitumstellung stattfinden sollen, eine Fehlermeldung angezeigt.

Als Entwickler und Objektdesigner weisen Sie Zeitzonenobjekte ausführbaren Objekten auf ihrer Seite Attribute zu. Beachten Sie Folgendes:

• Schedules und C_PERIOD-Objekte

  Wenn Sie ein Zeitzonenobjekt einer Schedule zuweisen, sind alle Startzeiten, die Sie für die Aufgaben innerhalb der Schedule angeben, lokale Zeiten der zugewiesenen Zeitzone.

• Jobs

  Die Zeitzone, die einem Job zugewiesen ist, hat keine Auswirkung auf die Zeit, zu der das Objekt ausgeführt wird. Stattdessen wirkt sie sich auf die Script-Funktionen aus, die Sie auf seinen Prozess-Seiten verwenden (z. B. SYS_TIME oder SYS_DATE).

Im Bereich Allgemeine Einstellungen können Zeitzonenobjekte unterschiedliche Spezifikationen für einzelne Jahre speichern. Diese Funktion erleichtert die Integration von Datumsmodifikationen.

Beispiel:

Ein Zeitzonenobjekt enthält die Einstellungen für den Wechsel von Standard- auf Sommerzeit. Die Regierung des Landes, für das die jeweilige Zeit gilt, beschließt, diese Zeitänderungen einzustellen. Diese Entscheidung tritt in zwei Jahren in Kraft. Sie können das Zeitzonenobjekt erstellen und in zwei Jahren Anwenden ab dem Jahr einstellen.

Achtung! Es ist auch möglich, ein Zeitzonenobjekt in dem Jahr anzupassen, in dem die Zeit geändert wird. Dabei würden die Objekt-Aufzeichnungen (Liste von Ausführungen) der Vorjahre betroffen sein, da sie falsche Werte anzeigen würden, weil sie die neuen Angaben für das Zeitzonenobjekt verwenden.

Als Administrator, der für die Definition der Zeitzonenobjekte zuständig ist, aktivieren und konfigurieren Sie in der Zeitzonenobjektdefinition die Option Sommerzeit definieren, um sicherzustellen, dass die Prozesse trotz der Verschiebungen zwischen Sommerzeit und Standardzeit immer genau ablaufen.

Für gewöhnlich wird die lokale Uhrzeit um 02:00:00 eine Stunde vor- bzw. zurückgestellt. Das bedeutet, dass die Stunde zwischen 02:00:01 und 02:59:59 entweder nicht existiert oder zweimal vorhanden ist. Wenn Sie diese Option aktivieren und richtig konfigurieren, wird dies in jedem Fall in allen Objekten berücksichtigt, denen die Zeitzone zugeordnet ist.

Sie legen fest, dass die Uhr am 5. Sonntag im März um 02:00:00 Uhr um 60 Minuten vorgestellt wird.

Hinweis: Wenn der definierte Monat nicht 5 Sonntage enthält, verweist die Definition des 5. Sonntags auf den letzten Wochentag dieses Monats.

Das bedeutet, dass zwischen 02:00:01 und 02:59:59 eine Stunde verloren geht. Wenn Sie diese Option aktivieren, werden alle geplanten Aufgaben wie üblich verarbeitet, zum Beispiel auch alle Aufgaben, die für 02:30:00 geplant wurden.

Ebenso werden zwei verbundene Aufgaben, die mit einer Stunde Differenz geplant sind, also zum Beispiel eine um 02:30:00 und die andere um 03:30:00, unabhängig von der Uhrzeit mit einem Zeitversatz von 30 Minuten verarbeitet.

Sie geben an, dass die Uhr am 1. Sonntag im November um 02:00:00 Uhr 60 Minuten zurückgestellt wird:

Das bedeutet, dass die Stunde zwischen 01:00:01 und 01:59:59 zweimal vorhanden ist. Eine Aufgabe, die für 02:30:00 geplant ist, wird nicht zweimal verarbeitet, da das System weiß, dass sie bereits verarbeitet wurde.

Ebenso werden zwei verbundene Aufgaben, die mit einer Stunde Differenz geplant sind, also zum Beispiel eine um 01:30:00 Uhr und die andere um 02:30:00 Uhr, unabhängig von der Uhrzeit mit einem Zeitversatz von 120 Minuten verarbeitet.

Zeitumstellungen beeinflussen auch die Ereignisse, die in regelmäßigen Intervallen ausgelöst werden. Die Aktivierung des Ereignisses wird nicht mit den Zeitzonenobjekt-Definitionen synchronisiert.

Beispiel 1 (Umstellung auf Sommerzeit im Frühjahr):

Ein Ereignis wird alle vier Stunden ausgelöst, beginnend um 08:00. Es wird daher um 12:00, 16:00, 20:00, 00:00, 04:00, 08:00 und so weiter erneut ausgelöst.

Am 5. Sonntag im März wird die Uhr um 02:00:00 um eine Stunde vorgestellt. Das Ereignis wird daher um 12:00, 16:00, 20:00, 00:00, 05:00, 09:00, 13:00 etc. erneut ausgelöst. Das Intervall von vier Stunden wird eingehalten, da zwischen 00:00 und 05:00 eine Stunde verloren geht.

Angenommen das Intervall ist so eingestellt, dass das Ereignis am 5. Sonntag im März um 02:30:00 ausgeführt werden soll, also in der Stunde, die verloren geht. In diesem Fall wird das Ereignis zur nächsten vollen Stunde, d.h. in unserem Beispiel um 03:00:00, ausgeführt.

Beispiel 2 (Umstellung auf Sommerzeit im Frühjahr):

Ein Ereignis wird in Intervallen von 20 Minuten ausgelöst und die erste Prüfzeit ist 01:49. Die nächste Prüfzeit sollte also 02:09 sein. Da diese Stunde aufgrund der Zeitänderung fehlt, wird das Ereignis um 03:00 Uhr ausgeführt. Das heißt, dass das Intervall nur in dieser Instanz 11 Minuten lang ist. Die Ausführung wird mit 03:00 als neue Ausführung fortgesetzt und um 03:20, 03:40 und so weiter ausgeführt. Alle Ausführungen nach der Zeitänderung halten das ursprüngliche Intervall ein. Wenn jedoch eine Ausführung nicht jeweils zur vollen Stunde ab Start stattfindet, ist sie möglicherweise nicht auf den Start ausgerichtet. Der Grund für dieses Verhalten ist, dass EH_NEXTCHECK, UTC in die Ortszeit (des Mandanten oder Objekts) neu berechnen muss, um sicherzustellen, dass z. B. Workflow oder Kalender mit Zeiteinstellungen richtig ausgeführt werden.

Beispiel 3 (Umstellung auf Winterzeit im Herbst):

Bei der Umstellung auf die Winterzeit werden Ereignisse kein zweites Mal ausgeführt, nachdem die Umstellung erfolgt ist. Nehmen wir an, wir haben ein Ereignis, das alle 20 Minuten ausgeführt wird; normalerweise um 12:00 Uhr, 12:20 Uhr, 12:40 Uhr, 13:00 Uhr, 13:20 Uhr, 13:40 Uhr, 14:00 Uhr, 14:20 Uhr, 14:40 Uhr, 15:00 Uhr usw. Dieses Ereignis wird nur beim ersten Mal zwischen 13:00 und 14:00 Uhr an dem Tag ausgeführt, an dem die Zeitzone auf Auf Normalzeit zurücksetzen eingestellt ist. Das heißt, es wird um 12:00 Uhr, 12:20 Uhr, 12:40 Uhr, 13:00 Uhr, 13:20 Uhr und 13:40 Uhr ausgeführt. Dann wird es eine Stunde lang nicht ausgeführt und anschließend wieder um 14:00, 14:20, 14:40, 15:00 usw. ausgeführt.

Wichtig! Beachten Sie dieses Verhalten unbedingt, wenn im Ereignisobjekt ein Kalender mit Zeitraum definiert ist. In diesem Fall verschieben sich die Auslösezeitpunkte, die somit nach der Zeitumstellung innerhalb bzw. außerhalb dieses Zeitraums liegen können. Starten Sie das Ereignisobjekt über eine Schedule, um eine solche Situation zu vermeiden. Beim Periodenwechsel wird der Startzeitpunkt des Ereignisses dann an die Sommer- bzw. Winterzeit angepasst.

Sie können Clients, Benutzern, Queues, Scripts und ausführbaren Objekten Zeitzonenobjekte zuweisen. Für alle Objekte gilt Folgendes:

• Wenn Sie einem Objekt eine Zeitzone zuweisen, gilt diese und überschreibt die Zeitzonenobjekte, die dem Client und Client 0 zugeordnet sind (falls vorhanden).
• Wenn Sie einem Objekt keine Zeitzone zuweisen, wird die des Clients übernommen.
• Wenn dem Mandanten keine Zeitzone zugewiesen ist, gilt UTC.
• Wenn im Client 0 keine Zeitzone definiert ist, gilt UTC.

Hinweise:

• Aufgaben in Workflows verwenden die im Workflow definierte Zeitzone, es sei denn, Sie weisen ihnen auf der Registerkarte Zeit und Abhängigkeiten-Eigenschaften eine bestimmte Zeitzone zu, siehe Konfigurieren der Zeit- und Abhängigkeitseigenschaften einer Aufgabe in einem Workflow.
• Aufgaben in Schedules verwenden die im Schedule definierte Zeitzone

• Auch bei vielen Script-Elementen kommen Zeitzonen zum Einsatz. In den folgenden werden Zeitzonen als Parameter zugewiesen.

  • CONV_TIMESTAMP
    Rechnet Datum und Uhrzeit für die Verwendung in einer anderen Zeitzone um
  • SYS_DATE
    Ermittelt das aktuelle Datum zu Beginn der Script-Verarbeitung
  • SYS_DATE_PHYSICAL
    Gibt das aktuelle Datum zurück
  • SYS_TIME
    Gibt die aktuelle Tageszeit zu Beginn der Script-Verarbeitung zurück
  • SYS_TIME_PHYSICAL
    Ermittelt die aktuelle Tageszeit
  • SYS_TIMESTAMP_PHYSICAL
    Stellt das aktuelle Datum und die aktuelle Uhrzeit bereit