Project

General

Profile

Support Request #1424

ADTFS-48146 Using DateTime::ToTimeStamp leads to unexpected timestamp

Added by hidden almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Requester's Priority:
Normal
Topic:
FileLibrary::Common
Resolution:
Known Problem
Platform:
Ubuntu 16.04 64bit, Windows 7 64bit
FAQ Links:

Description

Supportanfrage

Hallo,

beim Ausgeben der Zeitstempel aus der ADTF File library ist uns noch etwas aufgefallen:

Verwendung der ADTF File Lib:
::a_util::datetime::DateTime dt{ ::a_util::datetime::get_current_local_date_time( ) };
auto ts = dt.ToTimeStamp( );

Hier erhalte ich sowas: 212378801678930000
Leider ist nicht klar, welche Einheit. Ich vermute aber, da in ADTF Timestamp immer Mikrosekunden hat, dass es das hier auch ist.

Verwendung der C++ Standart Lib:

C++ Standard Lib:
auto now = std::chrono::duration_cast<std::chrono::milliseconds>( std::chrono::system_clock::now( ).time_since_epoch( ) ).count( );

Im Vergleich dazu ist hier das Ergebnis: 1511994878930 ms
Einheit ist hier klar definiert. Das ist die Zeit seit dem 1.1.1970 (Unix Time, siehe auch https://www.epochconverter.com/ und https://en.wikipedia.org/wiki/Unix_time).

212378801678930000 / 1000 => 212378801678930

Im Vergleich:
212378801678930 ms
1511994878930 ms

Wenn ich die Ausgabe der C++ Standard Lib durch 1000 teile (um Sekunden zu erhalten) und an die DB gebe, sehe ich das korrekte Datum.
Eine Vermuting, dass der ADTF File Lib Timestamp nicht Unix Epoch ist, sondern seit dem 1.1.1900 zählt scheint auch nicht zu passen. Das wären:
3720984789 s

Könnt Ihr uns beschreiben was der Timestamp der ADTF File Lib für ein Wert ist? In der Doku haben wir dazu auch nichts gefunden.

Danke und Grüße,
Anja

Lösung

  • Es liegt kein Bug vor (nur wenn man davon ausgeht, dass DateTime::ToTimeStamp einen UTC Wert bezogen auf Unixzeit liefert... was aber naheliegend wäre, wenn man sich die UTC Zeit mit Referenz zu Unix-Nullpunkt ins DateTime Objekt holt)
  • Der Rückgabewert der DateTime::ToTimeStamp Methode ist Mikrosekunden
  • Der Referenzpunkt ist der Nullpunkt des Julianischen Datums.
  • Dazu habe ich das Snippet erweitert:

siehe utc_ref_timestamp = 1. Januar 1970, 00:00 Uhr UTC

210866803200000000 us
210866803200000 ms
210866803200 s
58574112 h
240588 d
~6682 y

1970 - 6682 = -4712

  • 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
  • Mit Hilfe des Unixzeitpunkt Referenzpunktes (siehe Snippet utc_ref_timestamp) kannst du den Wert in Unix/UTC umrechnen und abzüglich Rechenzeit entspricht das Chrono
  • Wir werden in ODAUTIL-77 die Doku entsprechend erweitern

Files

convert_chrono.png (19.9 KB) convert_chrono.png hidden, 2017-12-01 17:32
time_test_snippet.JPG (69.8 KB) time_test_snippet.JPG hidden, 2017-12-01 17:32
code_snippet_datetime.JPG (105 KB) code_snippet_datetime.JPG hidden, 2017-12-05 12:10
#1

Updated by hidden almost 4 years ago

  • Project changed from Public Support to 7
  • Status changed from New to In Progress
  • Topic set to FileLibrary::Common
  • Affected Products ADTF File Library / IFHD 0.1.0 (BETA) added
  • Platform Ubuntu 16.04 64bit, Windows 7 64bit added
#2

Updated by hidden almost 4 years ago

  • Status changed from In Progress to Customer Feedback Required

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( ) };
#3

Updated by hidden almost 4 years ago

Hallo Florian,

Worauf bezieht sich der Zeitstempel (welchen Startzeitpunkt)? Es ist keine Unix Time. Ist es der 1.1.0000? Ich habe gerade mit Fabian gesprochen und das ist uns immer noch nicht klar.

Grüße,
Anja

#4

Updated by hidden almost 4 years ago

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.

#5

Updated by hidden almost 4 years ago

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 ?

#6

Updated by hidden almost 4 years ago

Hallo Florian,

aber irgendwie passt das mit dem Referenzpunkt Christi Geburt nicht so ganz. Wenn wir den Rückgabewert der DateTime Funktion (212378801678930000) in Jahre umrechnen kommen wir auf rund 6.7298 Jahre.

Nach etwas Recherche haben wir herausgefunden das die Differenz wohl auf Grund der Verwendung von verschiedenen Kalendersystemen zurück zu führen ist.

Warum nehmt Ihr den Startpinkt des julianischen Kalenders als Referenz (1.1.4713 v.Chr. nach gregorianischen Kalender) und nicht die Unix Time (im gregorianischem Kalender definiert)r?

Wenn Ihr die Unix Time im UTC Format angeben würdet, wäre das gut.

Wenn das Ticket abgeschlossen ist dürft ihr das Ticket öffentlich machen.

#7

Updated by hidden almost 4 years ago

Ich meinte natürlich julianisches Datum und nicht julianischer Kalender.

Grüße,
Anja

#8

Updated by hidden almost 4 years ago

  • Product Issue Numbers changed from https://www.cip.audi.de/jira/browse/ACORE-8643 to https://www.cip.audi.de/jira/browse/ODAUTIL-77

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.

#9

Updated by hidden almost 4 years ago

Hallo Florian,

alles klar. Danke.

Dann kann das Ticket geschlossen werden.

 

Viele Grüße,

Anja

EB Assist ADTF Support-Team

#10

Updated by hidden almost 4 years ago

  • Project changed from 7 to Public Support
  • Subject changed from ADTFS-48146 Ausgabe DateTime der ADTF FileLib to ADTFS-48146 Using DateTime::ToTimeStamp leads to unexpected timestamp
  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Private changed from Yes to No
#11

Updated by hidden almost 4 years ago

  • Status changed from To Be Closed to Closed

Also available in: Atom PDF