.."Jedes
DBMS das ich kenne (bzw das TDataSet von Delphi) hat einen passenden Typ (bzw.AsDateTime-Property für die Felder). Wie das intern gelöst wird muss einen doch gar nicht interessierw, oder?"...
Leider doch, denn es gibt kaum ein
DBMS, welches historisch stets richtig UTC Zeiten in die am jeweiligen Datum für eine bestimmte Zeitzone korrekt ausgibt und dazu via
SQL noch intern korrekt Offsets dazu oder weg rechnen kann.
Einfache
DBMS scheitern ja schon bei UTC Timestamps in der Tabelle, wenn die US Sommerzeit anders beginnt als die EU Sommerzeit. Wenn es aktuell geht, kapieren bestimmte Systeme einfach nicht das die erst seit Jahr XXXX gilt und es davor anders war... also auch wenn aktuell alles stimmt sollte man wenn es eine globale Anwendung mit auch historischen Daten ist, wirklich selbst alles sehr sehr genau testen, bzw. doch auf eine eigene Variante setzen.
Beispiel "SAP Zeitmodell":
https://help.sap.com/doc/abapdocu_75...zone_rules.htm
Das SAP Konzept ist gut und sehr universell, aber auch sehr langsam wenn es um Millisekunden geht, im HFT-Finanzbereich kommen zeit&speicher optimiertere Methoden zum Einsatz. Eigene ConvertTo/ConvertFrom sind dann die möglichst selten genutzen Funktionen um letztendlich wieder alles in StandardDBs zu speichern oder via Standard-GUIs/Reports zu visualisieren.