Ich bin kürzlich wieder über Zeitstempel, genauer den SQL Datentyp TIMESTAMP in MySQL gestolpert: Dieser unterstützt “nur” eine Genauigkeit von Sekunden, Millisekunden werden nicht gespeichert.
Über dieses Verhalten sind auch bereits einige andere gestolpert. Doch liegt das Problem nicht bei den Datenbanken.
Das eigentliche Problem wird durch die Millisekunden-Thematik überdeckt: Wie genau soll eine Uhrzeit gespeichert werden?
Intern legen die Datenbanken die Zeit als einen ganzzahligen Wert ab, üblicherweise als Offset zu einem fixen Zeitpunkt, wie Beispielsweise in Java als Millisekunden Different zwischen der aktuellen Zeit und Mitternacht des 1. Januars 1970 UTC. Also muss die gespeicherte Zeiteinheit bereits beim Definieren des Datentyps fix sein. Eine feinere Auflösung ist damit nicht mehr möglich.
Als die Datenbank-Entwickler den Datumstyp festlegten, erschien es ihnen als Sinnvoll, lediglich die Sekunden abzulegen. Bei heutigen Super-Multicore Rechnern sind aber Zeitauflösungen in den Nano- oder gar Pikosekundenbereich möglich, mit steigender Tendenz. Zum Beispiel wurde in Java die Wartefunktion für Threads (Thread.sleep()) um Nanosekunden erweitert, um diesem Sachverhalt nachzukommen.
Wenn man nun vor dem Problem steht, dass die Datenbank nicht die gewünschte Genauigkeit liefert, gibt es derzeit nur eine Lösung: Man macht seinen eigenen Datentyp, indem man die gewünschte Uhrzeit als Long Wert in eine Spalte speichert und diese dann manuell im Kode zu einer Zeit umwandelt. Dies führt natürlich dazu, dass man die SQL-Datums- und Zeitfunktionen nicht mehr benutzen kann.
Was hier eigentlich notwendig wäre ist eine Erweiterung des SQL-Standards um vom User definierte Genauigkeiten bei Zeitstempeln, ähnlich wie man es bereits für Fließkommazahlen definieren kann. So kann man nach dem SQL-Standard mit DECIMAL(n, m) eine Dezimalzahl mit beliebig genauen Vorkomma- und Nachkommastellen festlegen. Entsprechend wäre eine Definition von TIMESTAMP(n) sinnvoll, bei der man die Genauigkeit nach den Sekunden festlegen kann. Entsprechende Erweiterungen an den SQL-Datums- und Zeitfunktionen wären ebenfalls notwendig.
