Public Support

Hallo Anja,

da die Implementierung ja komplett offen ist (siehe ATUILS for IFHD), könnt ihr das ja auch selbst prüfen und ggf. für euren Use Case anpassen.

Ihr verwendet die Local Time

::a_util::datetime::DateTime dt{ ::a_util::datetime::get_current_local_date_time( ) };

Deshalb wird auch die LocalTime zurückgegeben, bei Windows Verwendung von GetLocalTime.

Wenn der Use Case die System Zeit in UTC ist, dann bitte auch entsprechend GetSystemTime verwenden.

::a_util::datetime::DateTime dt{ ::a_util::datetime::get_current_system_date_time( ) };

Hi Anja,

der Rückgabewert von DateTime::ToTimestamp() sollte in Microsekunden sein wenn ich die Funktion anschaue (siehe Code).
Allerdings kann das so nicht stimmen, da gebe ich dir recht.
1. passt die Größenordnung nicht (Faktor 100)
2. der Wert an sich

Ich habe das ganze auch mal verglichen und bekomme folgendes Ergebnis (Hinweis wegen der Funktionsaufrufe, das ist eine neuere Version aber Code gleich, nur die Namen haben sich geändert):

Hier sieht man schön den Unterschied zwischen Local und UTC, die DateTime Objekte sind korrekt gefüllt, der Diff der Timestamps entspricht auch einer Stunde = Zeitzone + 1, soweit so gut.

Allerdings liefert das DateTime::ToTimestamp() scheinbar falsche Werte zurück, wie oben beschrieben.

Nimmt man den Wert der std-chrono und konvertiert diesen, entspricht es dem Wert der Aufzeichnung (vgl. DateTime Objekte):

Den Rückgabewert der DateTime::ToTimestamp() kann man a) gar nicht konvertieren und b) kommt beim kürzen der zwei Nullen ein Jahr 2037 usw. heraus.

Ich gebe das mal an die Utils-Entwickler weiter und melde mich dann wieder.

Hallo Anja,

ich habe das Thema ausführlich mit den Utils Entwicklern besprochen und komme zu folgenden Schluss:

• Es liegt kein Bug vor (nur wenn man davon ausgeht, dass DateTime::ToTimeStamp einen UTC Wert liefert... was aber naheliegend wäre, wenn man sich die UTC Zeit ins DateTime Objekt holt)
• Der Rückgabewert der DateTime::ToTimeStamp Methode ist Mikrosekunden
• Der Referenzpunkt ist Christi Geburt, also das Jahr 0
• Dazu habe ich das Snippet erweitert:

• Da die DateTime::Set Methode bzw. Konstruktoren von DateTime genauso implementiert sind, kann man das DateTime Objekt wieder rekonstruieren, die Implementierung, Format und Referenz ist demnach konsistent
• Ich würde dennoch gerne das bestehende Ticket, dass wir 2018 angehen wollten (ACORE-8643 [Clock Service] provide option to use unixtime (UTC)), gleich umsetzen und die DateTime Funktionen so umstellen, dass sie UTC Timestamps liefern/verarbeiten können
• Damit wär ADTF 3.x / ADTF File Library auf UTC umgestellt
• Dazu müsste imho auch die File Version umgestellt werden, um nicht inkonsistent zu werden
• Mit Hilfe des UTC Referenzpunktes (siehe Snippet utc_ref_timestamp) kannst du den Wert in UTC umrechnen und abzüglich Rechenzeit entspricht das Chrono

Geht ihr soweit mit ?
Wenn ja, darf ich dieses Ticket öffentlich machen bzw. in FAQ aufnehmen ?

Da hast du recht, die Basis ist der Nullpunkt der astronomischen Zeitskala Julianisches Datum, eben auch nochmal nachgerechnet.
Wir haben leider den Offset übersehen, der noch hinzukommt, deshalb die Annahme mit 0.

Wir werden das entsprechend dokumentieren und angeben, wie man auf Unix Zeit kommt.
Ändern werden wir es doch nicht auf Unix, da das sonst zu Inkonsistenten im DAT File führt.

Wer lieber Unix Zeit haben möchte, kann sich ja die Methoden umschreiben oder zusätzliche verwenden, der Source ist ja offen.
Es muss nur beachtet werden, dass dann die ganze Toolkette darauf angepasst werden muss.

Deshalb wäre nur die Umrechnung empfehlenswert.

Wenn keine Fragen mehr sind, würde ich das Ticket abschließen.