Folgende Themen werden behandelt:
Die Natural-Systemvariable
*TIMESTMP
liefert den maschineninternen Store Clock-Wert, wie er durch die
Großrechner-Maschineninstruktion STCK (Store Clock
Format) bereitgestellt wird. Der Store Clock ist ein 8 Byte langes binäres
Feld. Er zählt die Mikrosekunden seit 01.01.1900 00:00:00 (UTC), wobei
Bitposition 51 exakt eine Mikrosekunde darstellt (Bitposition 0
ist das ganz linke Bit). Die übrigen Bits können je nach
Maschinenimplementierung höhere Genauigkeitswerte wie Nanosekunden oder eine
Prozessorkennung (ID) enthalten.
Der Store Clock wird seinen höchstmöglichen Wert am 17. September
2042 um 23:53:47.370495 (UTC) erreichen, wobei dann alle 52 Bits auf
1 gesetzt sein werden. Danach wird der Store Clock-Zähler
zurückgesetzt und es wird wieder ab 0 hochgezählt. Das Datum, an
dem die Uhr zurückgestellt wird, wird im Folgenden als Rücksprungdatum
(Wrap Date) bezeichnet.
Nach dem Rücksprungdatum wird der Store Clock dieselben Werte wie im Bereich von 1900 bis 2042 verwenden. Deshalb ist es nicht möglich zu entscheiden, ob ein Store Clock vor oder nach dem Rücksprungdatum genommen wurde.
Wenn der Store Clock die Jahre von 1900 bis 2042 abdeckt, nennen wir ihn den "originalen Store Clock".
Für das Jahr 2042 ist Folgendes zu beachten ("Jahr-2042-Problem"):
Vergleich und Sortierung
Ein Vergleich von zeitbezogenen Werten sollte die chronologische
Reihenfolge so widerspiegeln, dass frühere Werte kleiner als spätere Werte
sind. Leider ist ein Store Clock-Wert, der kurz vor dem Rücksprungdatum
genommen wurde, größer als ein Store Clock-Wert, der nach dem Datum genommen
wurde, an dem der Store Clock auf 0 gestellt wurde. Somit führt
ein Vergleich solcher Store Clock-Werte zu unrichtigen Ergebnissen. Beispiel:
Der Store Clock-Wert vom 01.01.2040 (vor dem Rücksprungdatum) ist größer als
der Store Clock-Wert vom 01.01.2043 (nach dem Rücksprungdatum). Sortiert man
Store Clock-Werte, die vor und nach dem Rücksprungdatum genommen wurden, werden
diese nicht die chronologische Reihenfolge widerspiegeln. Ein
READ-Statement, das die genannten Werte als Start- und Endwerte
verwendet, wird keinen Wert zurückgeben, da der Endwert kleiner ist als der
Startwert.
Konvertierung
Wenn man einen Store Clock-Wert in ein Datum konvertiert, wird
davon ausgegangen, dass er in den Jahren von 1900 bis 2042 genommen wurde.
Wurde der Store Clock-Wert aber tatsächlich nach dem Rücksprungdatum genommen,
wird die Konvertierung deshalb zu einem falschen Ergebnis führen. Beispiel: Ein
Store Clock-Wert wurde am 07.12.2043 (d.h. nach dem Rücksprungdatum) genommen.
Wenn man diesen Store Clock-Wert in ein Datum konvertiert, wird das Ergebnis
der 21.03.1901 sein.
Berechnung einer Zeitdifferenz
Wenn man Store Clock-Werte in Mikrosekunden konvertiert, kann
man sie zur Berechnung einer Zeitdifferenz benutzen. Das funktioniert
problemlos, falls das Rücksprungdatum nicht beteiligt ist. Wenn man einen
(großen) Store Clock-Wert, der vor dem Rücksprungdatum genommen wurde, von
einem (kleinen) Store Clock-Wert, der nach dem Rücksprungdatum genommen wurde,
subtrahiert, erhält man ein falsches (und zwar negatives) Ergebnis. Beispiel:
Wenn man die Store Clock-Zeitdifferenz zwischen den Jahren 2039 und 2043
berechnet, erhält man -138 Jahre als Ergebnis.
Die Zeit, in der wir nur Store Clock-Werte kleiner als das Rücksprungdatum (17.09.2042) verarbeiten, bezeichnen wir als Übergangszeit. Während dieser Zeit sollten die ursprünglichen Store Clock-Werte durch einen der in den folgenden Abschnitten beschriebenen Lösungsansätze ersetzt werden.
Um das Jahr-2042-Problem zu lösen, gibt es folgende Ansätze:
Temporärer Ansatz: Store Clock mit gleitendem
Jahr-Fenster.
Der Store Clock mit gleitendem
Jahr-Fenster interpretiert den Store Clock-Wert in einem gleitendem
Jahr-Fenster. Er unterstützt den Zeitbereich von 1971 bis 2114. Die binären
Werte können nicht zum Sortieren oder Vergleichen verwendet werden.
Genereller Ansatz: Erweiterter Store Clock.
Der erweiterte Store Clock ist
16 Bytes lang und unterstützt den Zeitbereich von 1900 bis 38434. Die binären
Werte können zum Sortieren und Vergleichen verwendet werden. Erweiterte Store
Clock-Werte sind nicht kompatibel zu Store Clock-Werten (weder original noch
mit gleitendem Jahr-Fenster). Daten und Programme, die sich auf Store
Clock-Werte beziehen, müssen in einem einzigen, großen Schritt auf erweiterte
Store Clock-Werte umgestellt werden.
Smarter Ansatz: Smarter Store Clock
Der smarte Store
Clock ist 9 Bytes lang und unterstützt den Zeitbereich von 1900 bis
38434. Die binären Werte können zum Sortieren und Vergleichen verwendet werden.
Während der Übergangszeit sind die smarten Store Clock-Werte mit den originalen
Store Clock-Werten kompatibel. Daten und Programme, die sich auf Store
Clock-Werte beziehen, können schrittweise in Smart Store Clock-Werte
umgewandelt werden. Dies ist der empfohlene Ansatz, um das Jahr-2042-Problem zu
lösen.
Für diese Ansätze stehen in der Natural System Library SYSEXT (siehe auch SYSEXT Utility) Anwendungsprogrammierschnittstellen (APIs) zur Verfügung, siehe Natural-APIs zur Store Clock-Verarbeitung.
Wenn ein Store Clock-Wert in ein Datum konvertiert wird, wird bei der Konvertierung des originalen Store Clock-Wertes davon ausgegangen, dass er aus dem Bereich von 1900 bis 2042 genommen wurde. Um den Bereich zu erweitern, verwenden wir ein "gleitendes Jahr-Fenster" (Year Sliding Window), das den Bereich von 1971 bis 2114 unterstützt. Das impliziert, dass die Jahre von 1900 bis 1971 nicht mehr unterstützt werden.
Im Jahr 1971 schaltet das erste Bit im Store Clock-Wert auf
1. Deshalb wird dieses Bit zur Realisierung des gleitenden
Jahr-Fensters genutzt:
Von 1971 bis 2042 ist das erste Bit 1. Store
Clock-Werte aus diesem Bereich werden wie zuvor interpretiert.
Von 1900 bis 1971 und von 2042 bis 2114 ist das erste Bit
0. Mit dem gleitendem Jahr-Fenster werden diese Store Clock-Werte
als 2042 bis 2114 interpretiert.
Wenn ein Store Clock-Wert mit gleitendem Jahr-Fenster in
Mikrosekunden konvertiert wird und das erste Bit 0 ist, wird vor
der Konvertierung der binäre Store Clock-Wert auf der linken Seite mit
x'01' erweitert, damit das Ergebnis immer die Anzahl an
Mikrosekunden seit dem 01.01.1900 widerspiegelt.
Der Bereich des Store Clock mit gleitendem Jahr-Fenster
beginnt am 11.05.1971 um 11:56:53,685248 Uhr (UTC) und
endet am 26.01.2114 um 11:50:41,055743 Uhr (UTC).
Anmerkungen:
NULL-Wert), dann ist
das Feld noch unbenutzt und es wurde noch kein Store Clock-Wert gespeichert.
Sie müssen sicherstellen, dass das Store Clock-Feld keinen
NULL-Wert enthält, bevor Sie es in einer Konvertierungsfunktion
benutzen.
Im Vergleich zum originalen Store Clock bietet der Store Clock mit gleitendem Jahr-Fenster folgende Verbesserungen:
Konvertierung
Natural APIs können benutzt werden, um Store Clock-Werte mit
gleitendem Jahr-Fenster richtig zu konvertieren, wenn die Store Clock-Werte im
Zeitraum von 1971 bis 2114 genommen worden sind.
Berechnung einer Zeitdifferenz
Zum Konvertieren von Store Clock-Werten mit gleitendem
Jahr-Fenster in Mikrosekunden (seit 01.01.1900) können Natural-APIs benutzt
werden. Eine Zeitdifferenzberechnung mit diesen Werten liefert die richtige
Zeitdauer (wenn die Store Clock-Werte von 1971 bis 2114 sind).
Ausblick
Das Jahr-2042-Problem wird bis 2114 hinausgeschoben.
Im Vergleich zum smarten oder zum erweiterten Store Clock bietet der Store Clock mit gleitendem Jahr-Fenster die folgenden temporären Vorteile:
Größe
Die Größe des Store Clock-Werts bleibt bei 8 Bytes.
Datenkonvertierung (im Vergleich zum erweiterten Store
Clock
Es besteht keine Notwendigkeit, die Store Clock-Daten auf 16
Byte lange Werte zu konvertieren. Gespeicherte 8 Byte lange Store Clock-Daten
werden richtig interpretiert, wenn sie im Bereich 1971 bis 2114 sind.
Änderungen an Programmen
Die Konvertierung erfordert nur einen geringen Änderungsaufwand.
Die Systemvariable *TIMESTMP
kann weiterhin benutzt werden.
Vor einer Migration vom originalen Store Clock zum Store Clock mit gleitendem Jahr-Fenster ist Folgendes zu berücksichtigen:
Vor Ende des gleitenden Jahr-Fensters im Jahre 2114 werden weitere Codeänderungen erforderlich.
Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie diese API durch eine API ersetzen, die den Store Clock mit gleitendem Jahr-Fenster unterstützt.
Wenn Sie binäre Store Clock-Werte vergleichen oder sortieren, werden diese nicht in chronologischer Reihenfolge sein. Siehe Anmerkung weiter oben.
Die Natural-Systemvariable
*TIMESTMPX
liefert den maschineninternen erweiterten Store Clock-Wert, so wie er durch die
Großrechner-Instruktion STCKE (Store Clock Extended Format) zur
Verfügung gestellt wird. Der erweiterte Store Clock ist ein 16 Byte langes
binäres Feld. Er zählt die Mikrosekunden seit dem 01.01.1900 00:00:00 (UTC),
wobei Bitposition 59 exakt eine Mikrosekunde darstellt (Bitposition
0 ist das ganz linke Bit). Die originale Store
Clock-Zeitdarstellung wird in Byte 2 bis 9 beibehalten. Links wird ein
zusätzliches Überlauf-Byte hinzugefügt, der so genannte Epochen-Index.
Der erweiterter Store Clock deckt die Jahre von 1900 bis 38434 ab.
Im Vergleich zum originalen Store Clock bietet der erweiterte Store Clock folgende Verbesserungen:
Vergleich und Sortierung
Wenn man Werte vergleicht oder sortiert, liefert der erweiterte
Store Clock immer die erwartete chronologische Reihenfolge.
Konvertierung
Zum Konvertieren von erweiterten Store Clock-Werten können
Natural-APIs benutzt werden. Weil jeder erweiterte Store Clock-Wert im
erweiterten Store Clock-Wertebereich eindeutig ist, ist die Berechnung immer
richtig.
Berechnung einer Zeitdifferenz
Zum Konvertieren von erweiterten Store Clock-Werten in
Mikrosekunden (seit 01.01.1900) können Natural-APIs benutzt werden. Eine
Zeitdifferenzberechnung mit diesen Werten liefert die richtige Zeitdauer.
Ausblick
Für die Zukunft ist keine weitere Codeänderung erforderlich.
Vor einer Migration vom originalen Store Clock zum erweiterten Store Clock ist Folgendes zu berücksichtigen:
Die Größe des binären Feldes erhöht sich von 8 Bytes auf 16 Bytes.
Erweiterte Store Clock-Werte sind nicht kompatibel mit Store Clock-Werten im Format B8. Es ist nicht möglich, einen Store Clock-Wert in einen erweiterten Store Clock-Wert zu verschieben oder umgekehrt.
Beispiel:
#STORECLOCK: DD943485BC302002 MOVE #STORECLOCK TO #EXTENDED Erhalten: 0000000000000000DD943485BC302002 Erwartet: 00DD943485BC30200200000000000000
Ein erweiterter Store Clock-Wert kann nicht direkt mit einem originalen Store Clock-Wert verglichen werden (und auch nicht mit einem Store Clock-Wert mit gleitendem Jahr-Fenster). Der erweiterte Store Clock-Wert enthält sieben auf der rechten Seite hinzugefügte zusätzliche Bytes. Daher wird ein Vergleich kein richtiges Ergebnis liefern.
Gespeicherte Store Clock-Werte müssen in erweiterte Store Clock-Werte konvertiert werden. Für diese Aufgabe können Sie den Copycode USR9201R benutzen.
Wenn Store Clock-Werte im Format B8 in Adabas gespeichert werden, müssen Sie die Daten so editieren, dass das neue Feld vom Format B16 richtige erweiterte Store Clock-Werte enthält.
Jedes Programm, das Store Clock-Werte verarbeitet, muss an erweiterte Store Clock-Werte angepasst werden. Weil aber Store Clock-Werte und erweiterte Store Clock-Werte nicht kompatibel sind, müssen die Änderungen in einem einzigen Schritt erledigt werden.
Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie sie durch eine API ersetzen, die den erweiterten Store Clock-Wert unterstützt.
Diese komplette Konvertierung erfordert größere Änderungen.
Es wird empfohlen, statt des erweiterten Store Clock den smarten Store Clock zu verwenden. Dies wird im folgenden Abschnitt beschrieben.
Der smarte Store Clock ist ein 9 Byte langes binäres Feld. Es zählt die Mikrosekunden seit dem 01.01.1900 00:00:00 (UTC), wobei Bitposition 59 exakt eine Mikrosekunde darstellt (Bitposition 0 ist das ganz linke Bit). Die Zeitdarstellung des originalen Store Clock wird in Byte 2 bis 9 beibehalten. Auf der linken Seite wird ein zusätzliches Überlaufbyte hinzugefügt, der so genannte Epochen-Index. Mit anderen Worten: Der smarte Store Clock umfasst die ersten 9 Bytes des erweiterten Store Clock.
Der smarte Store Clock deckt die Jahre von 1900 bis 38434 ab.
Im Vergleich zum originalen Store Clock bietet der smarte Store Clock folgende Verbesserungen:
Vergleich und Sortierung
Wenn man Werte vergleicht oder sortiert, liefert der smarte
Store Clock immer die erwartete chronologische Reihenfolge.
Konvertierung
Zum Konvertieren von smarten Store Clock-Werten können
Natural-APIs benutzt werden. Weil jeder smarte Store Clock-Wert im smarten
Store Clock-Wertebereich eindeutig ist, ist die Interpretation immer
richtig.
Berechnung einer Zeitdifferenz
Zum Konvertieren von smarten Store Clock-Werten in Mikrosekunden
(seit 01.01.1900) können Natural-APIs benutzt werden. Eine
Zeitdifferenzberechnung mit diesen Werten liefert die richtige Zeitdauer.
Ausblick
Für die Zukunft ist keine weitere Codeänderung erforderlich.
Vor einer Migration vom originalen Store Clock zum erweiterten Store Clock ist Folgendes zu berücksichtigen:
Die Größe des binären Feldes erhöht sich von 8 Bytes auf 9 Bytes.
Während des Übergangszeitraums:
Erhöht man die Länge des originalen Store Clock-Wertes von
B8 nach B9, erhält man den richtigen smarten Store Code-Wert. Der Grund dafür
ist, dass in Natural und Adabas binäre Felder rechtsbündig sind. Durch
Vergrößerung der Länge wird das Überlaufbyte mit H'00'
gefüllt.
Smarte Store Clock-Werte sind kompatibel mit originalen Store Clock-Werten. Man kann einen originalen Store Clock-Wert in einen smarten Store Clock-Wert verschieben und umgekehrt.
Beispiel:
#STORECLOCK: DD943485BC302002 MOVE #STORECLOCK TO #SMART Erhalten: 00DD943485BC302002 Erwartet: 00DD943485BC302002
Smarte Store Clock-Werte können mit originalen Store Clock-Werten verglichen werden.
Jedes Programm, das Store Clock-Werte verarbeitet, muss an smarte Store Clock-Werte angepasst werden. Weil Store Clock-Werte und smarte Store Clock-Werte kompatibel sind, können die Änderungen schrittweise erledigt werden.
Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie sie durch eine API ersetzen, die den smarten Store Clock-Wert unterstützt.
Diese komplette Konvertierung erfordert geringfügige Änderungen.
Ein Feld, das Store Clock-Werte enthält, wird wie folgt definiert:
1 #TIMESTMP (B8) /* Originaler Store Clock-Wert
Ersetzen Sie die Definition durch:
1 #TIMESTMP (B9) /* Smarter Store Clock-Wert
Um den aktuellen Store Clock-Wert zu erhalten, wird das folgende Statement ausgeführt:
MOVE *TIMESTMP TO #TIMESTMP /* Aktuellen Store Clock-Wert ermitteln
Während des Übergangszeitraums kann das Statement noch verwendet
werden, auch wenn die Länge von #TIMESTMP auf B9 erhöht worden
ist. Langfristig sollte das Statement aber ersetzt werden durch:
INCLUDE USR9201F '*TIMESTMPX' '#TIMESTMP' /* Aktuellen Store Clock-Wert ermitteln
Alternativ können Sie aber auch eine Redefinition durchführen:
1 #TIMESTMPX (B16) /* Erweiterter Store Clock-Wert 1 REDEFINE #TIMESTMPX 2 #TIMESTMP (B9) /* Smarter Store Clock-Wert
Und das folgende Statement verwenden:
MOVE *TIMESTMPX TO #TIMESTMPX /* Aktuellen Store Clock-Wert ermitteln
Während des Übergangszeitraums können Store Clock-Werte von einem zum anderen verschoben werden, auch wenn die Länge des einen B9 und die des anderen noch B8 ist.
MOVE #TIMESTMP-A TO #TIMESTMP-B /* Store Clock-Wert verschieben
Bei einem Subprogramm wird ein Store Clock-Wert als Parameter verwendet:
1 #TIMESTMP (B8) /* Store Clock-Wert
Wenn Sie die Länge des Feldes auf B9 erhöhen und es Programme gibt, die es mit B8 aufrufen, wird das Programm fehlschlagen. Verwenden Sie in diesem Fall die folgende Definition:
1 #TIMESTMP (B9) BY VALUE RESULT /* Store Clock-Wert
Sobald alle Aufrufer Store Clock-Werte im Format B9 verwenden,
kann das BY VALUE RESULT entfernt werden.
Während des Übergangszeitraums können Store Clock-Werte miteinander verglichen werden, auch wenn die Länge des einen Werts B9 ist und die des anderen noch B8 ist.
IF #TIMESTMP-A > #TIMESTMP-B /* Store Clock-Werte vergleichen
Ein Feld, das Store Clock-Werte enthält, wird wie folgt definiert:
1,AA,8,B,...
Ersetzen Sie die Definition durch:
1,AA,9,B,...
Auf dem Großrechner können Sie dies mit dem Adabas Online Service oder dem Dienstprogramm ADADBS (Database Services) erreichen, unter Linux und Windows mit dem Dienstprogramm ADAFDU (File Definition). Beachten Sie, dass unter Linux und Windows ein Feld, das Store Clock-Werte enthält, mit der Option HF (high order first) definiert werden muss.
Aufgrund der Änderung der Länge enthält die Datenbank gültige smarte Store Clock-Werte. Es ist nicht notwendig, die Daten zu bearbeiten. Handelt es sich bei dem Feld um einen Deskriptor, liefert es die richtige chronologische Reihenfolge.
Auf der Natural-Seite müssen Sie das Datendefinitionsmodul (DDM) entsprechend ändern. Falls eine Länge angegeben ist, müssen Sie außerdem die zugehörigen Datensichten (Views) ändern.
Ein Feld AA, das Store Clock-Werte enthält, wird als
übergeordnetes Feld eines Superdeskriptors verwendet:
SA=AC(1,20),AA(1,8)
Während des Übergangszeitraums kann der Superdeskriptor auch dann noch weiterverwendet werden, wenn die Feldlänge des übergeordneten Feldes auf 9 Bytes erhöht worden ist. Das liegt daran, dass die Bytes in einem binären Feld von rechts nach links gezählt werden.
Langfristig sollte das Statement aber ersetzt werden durch:
SA=AC(1,20),AA(1,9)
Alle Variablen in Natural-Programmen (z.B. Start- und Endwerte), die sich auf den Superdeskriptor beziehen, müssen zusammen mit den Datenbankänderungen angepasst werden. Alternativ können Sie auch den ursprünglichen Superdeskriptor beibehalten und zusätzlich einen neuen Superdeskriptor mit der neuen Länge anlegen. Dann können Sie ein Programm nach dem anderen auf den neuen Superdeskriptor umstellen. Sobald alle Programme auf den neuen Superdeskriptor zugreifen, kann der alte Superdeskriptor freigegeben (gelöscht) werden.
Die Natural-Systemvariable *TIMX stellt
die lokale Uhrzeit (Ortszeit) in Zehntelsekunden zur Verfügung. Wird die lokale
Uhrzeit mit höherer Genauigkeit benötigt, kann die Natural API
USR9178N
verwendet werden. Sie liefert die lokale Uhrzeit und die entsprechende UTC-Zeit
im Store Clock-Format (B8), in Mikrosekunden seit 01.01.1900 und im
Natural-Zeitformat (T). Zusätzlich liefert sie die Zeitdifferenz, einen
Standard-DATETIME-Wert und die Zeitzone. Es sind Funktionen
vorhanden, mit denen die Werte in andere Formate konvertiert werden können. Die
Copycodes USR9178X, USR9178Y und
USR9178Z bieten im Prinzip die gleiche Funktionalität, jedoch bei
wesentlich besserer Performance.
Die ersten 7 Bytes des lokalen Store Clock-Werts haben den gleichen
Inhalt wie der originale Store Clock, wobei die Bitpositionen 0 – 51 die
Mikrosekunden der lokalen Uhrzeit enthalten. Deshalb können zur Interpretation
eines lokalen Store Clock-Werts Standard-APIs (z.B. USR1023* oder
USR9201*) verwendet werden.
Das letzte Byte eines mit USR9178* generierten lokalen
Store Clock-Werts enthält die Zeitdifferenz. Mit dieser Information kann später
festgestellt werden, in welcher Zeitzone der lokale Store Clock-Wert genommen
wurde, insbesondere, ob in der Sommer- oder der Winterzeit.
Die Zeitdifferenz drückt den Unterschied zwischen Local Time und UTC Time aus:
Zeitdifferenz = Local time - UTC time
Die API USR9178N
und die entsprechenden Copycodes liefern die Zeitdifferenz in Einheiten von
1/10 Sekunden.
Das letzte Byte eines lokalen Store Clock-Werts enthält die Zeitdifferenz in Einheiten von 15 Minuten als Ganzzahl mit Vorzeichen (Format I1).
Die API USR9178N gibt außerdem die der Zeitdifferenz
zugeordnete Zeitzone zurück.
-hh:ii bei einer
negativen Zeitdifferenz oder
+hh:ii andernfalls.
DATETIMEDie API USR9178N
gibt den Standard-DATETIME-Wert zurück:
yyyy-mm-ddThh:ii:ss.fff
dabei ist fff der Teilbetrag
in Millisekunden.
In der Natural Library SYSEXT (siehe SYSEXT Utility) stehen folgende Natural Anwendungsprogrammierschnittstellen (APIs) zur Verfügung:
| Natural API | Funktion | Store Clock | Vorgänger-Version | ||
|---|---|---|---|---|---|
| Original | mit gleitendem Jahr-Fenster | Smart / Erweitert | |||
| USR1009N | Store Clock mit gleitendem Jahr-Fenster in Mikrosekunden konvertieren | ja | ja | nein | |
| USR1023N | Zeitbezogene Systemvariablen konvertieren | ja | nein | nein | |
| USR9178N | Pflege von lokalen Store Clock-Werten | nein | ja | nein | |
| USR9201N | Zeitbezogene Variablen konvertieren | nein | ja | ja | USR1023N |
Die API USR1009N konvertiert einen Store Clock-Wert in Mikrosekunden seit 01.01.1900. Standardmäßig wird der Store Clock-Wert ohne gleitendes Jahr-Fenster (Bereich 1900-2042) interpretiert. Ein optionaler Parameter steht zur Verfügung, um den Store Clock-Wert mit dem gleitendem Jahr-Fenster (Bereich 1971-2114) zu interpretieren.
Die Copycodes USR9201V (mit gleitendem Jahr-Fenster) und USR1023Y (ohne gleitendes Jahr-Fenster) bieten bei besserer Performance die gleiche Funktionalität an wie die API USR1009N. Es wird daher empfohlen, diese Copycodes zu benutzen.
Die API USR1023N konvertiert eine zeitbezogene Variable in andere Formate. Sie verwendet dazu den originalen Store Clock (1900 – 2042).
Es wird dringend empfohlen, anstelle der API USR1023N die API USR9201N zu verwenden. Andernfalls werden Store Clock-Werte nach dem Jahr 2042 falsch interpretiert. Beispiel: Wenn Sie einen Store Clock-Wert am 07.12.2043 nehmen, wird ihn die API USR1023N als 21.03.1901 interpretieren.
Als Eingabe erwartet die API USR1023N eines der folgenden Formate:
Natural-Datum und Uhrzeit,
Natural-Datum,
Mikrosekunden (seit 01.01.1900) oder
originaler Store Clock.
Die API USR1023N konvertiert die Eingabe in alle anderen Formate.
Zusätzlich stehen zur API USR1023N die folgenden Copycodes zur Verfügung:
Die Copycodes sind wesentlich schneller als das Subprogramm USR1023N.
Die API USR9178N dient zur Pflege von lokalen Store Clock-Werten. Sie unterstützt Store Clock mit gleitendem Jahr-Fenster (1971 - 2114).
Bei der Funktion C gibt die API die folgenden aktuellen Werte zurück:
Lokaler Store Clock
UTC Store Clock
Zeitdifferenz in 1/10 Sekunden
Lokale Uhrzeit (Ortszeit) in Mikrosekunden
UTC-Uhrzeit in Mikrosekunden
Lokale Uhrzeit (Ortszeit) im Natural-Format (T)
UTC-Uhrzeit im Natural-Format (T)
Standard-DATETIME
Zeitzone
Bei der Funktion L konvertiert die API einen lokalen Store Clock-Wert in die anderen Formate.
Bei der Funktion U konvertiert die API einen UTC Store Clock-Wert und eine Zeitdifferenz in die anderen Formate.
Zusätzlich zu der API stehen die folgenden Copycodes zur Verfügung:
USR9178X - Aktuellen lokalen Store Clock, UTC Store Clock und Zeitdifferenz abfragen.
USR9178Y - Lokalen Store Clock in UTC Store Clock und Zeitdifferenz konvertieren.
USR9178Z - UTC Store Clock und Zeitdifferenz in lokalen Store Clock konvertieren.
Die API USR9201N ist der Nachfolger der API USR1023N. Sie unterstützt Store Clock mit gleitendem Jahr-Fenster (1971 - 2114), smarten und erweiterten Store Clock (1900 - 38434).
Als Eingabe erwartet die API USR9201N eines der folgenden Formate:
Natural-Datum und Uhrzeit,
Natural-Uhrzeit,
Natural-Datum,
Mikrosekunden (seit 01.01.1900),
Store Clock mit gleitendem Jahr-Fenster,
erweiterten Store Clock oder
smarten Store Clock.
Die API USR9201N konvertiert die Eingabe in alle anderen Formate.
Zusätzlich stehen zur API USR9201N die folgenden Copycodes zur Verfügung:
Anmerkung
Der Copycode USR9201D kann auch benutzt werden, um zwei Store
Clock-Werte miteinander zu vergleichen, wenn diese innerhalb des gleitenden
Jahr-Fensters (1971 - 2114) erfasst worden sind.
Die Copycodes sind wesentlich schneller als das API Subprogramm USR9201N.
Für einen Test mit 10.000 Konvertierungen benötigt:
das Subprogramm USR9201N etwa 35 ms und
der Copycode USR9201Y etwa 5 ms.