Ich habe überlegt, die begonnene GUI für Influx in ein Plugin für die sQLshell umzugestalten. Dafür muss die bestehende Implementierung noch poliert werden.

Während dieser Arbeiten bemerkte ich, dass einige der Measurements in Influx Zeitstempel aus der Zukunft aufzuweisen schienen. Bei näherer Inspektion mit dem offiziellen Kommandozeilen-Client stellte sich jedoch heraus, dass die Zeitstempel in der Datenbenk korrekt waren.

Irgendwo unterwegs wurde aus diesen korrekten Zeitstempeln die Zukunft. Irritierenderweise geschah das jedoch nicht bei allen Measurements: Einige wurden in der GUI auch korrekt dargestellt. eine nochmalige Inspektion im Kommandozeilen-Client förderte die Information zu Tage, dass die Zeitstempel in verschiedenen Formaten vorlagen: Es gab welche, die formatiert waren wie dieses Beispiel 2023-11-27T16:50:00Z und welche, die folgendes Format aufwiesen: 2023-11-27T15:51:03.510201204Z - das letztere war das Format, das die Schwierigkeiten verursachte.

Da ich ein Mensch bin, der alte Gewohnheiten schwer ablegt, parse ich die Timestamps, die mir die Influx-API als Strings liefert mit einem SimpleDateFormat. Der Formatstring dafür sieht wie folgt aus: yyyy-MM-dd'T'HH:mm:ss.SSS'Z' - Man sieht, dass ich die Millisekunden ebenfalls mit parsen möchte (SSS), um die Genauigkeit der Datenbank wenigstens annähernd in die GUI übertragen zu können.

Dieser Formatstring auf das Beispiel 2023-11-27T15:51:03.510201204Z angewendet liefert als Ergebnis Sun Dec 03 13:34:24 CET 2023 - eindeutig ein Fehler wenn man mit dem Wert aus dem Kommandozeilen-Client vergleicht. Die Abweichung ist zwar nur relativ gering, liegt aber um mehrere Tage in der Zukunft.

Nach einigem Forschen und ausführlicher Forensik fand ich den (aus meiner Sicht) nicht allzu intuitiven Mechanismus hinter dem Parsen von Timestamps mit Sub-Sekundengenauigkeit mit Javas SimpleDateFormat heraus:

Der Formatstring SSS bedeutet nicht "Nimm drei numerische Stellen und interpretiere sie als Millisekunden!". Tatsächlich bedeutet es: "Nimm alle numerischen Zeichen, die du findest und interpretiere sie als Millisekunden!". Und jetzt kommt die Auflösung der Zukunftszeitstempel: 510201204 wird nicht als 510,201204 Millisekunden verstanden, sondern als 510201204 Millisekunden - mit anderen Worten: als - schaut man nochmal auf das oben angegebene Beispiel, versteht man, warum der geparste Zeitstempel in der Zukunft lag: 100 Millionen Millisekunden ergeben etwas weniger als 6 Tage!

Interessant ist hierbei jedoch noch folgendes: Die Nutzung der neuen Klassen in Package java.time hilft dabei, das Problem zu umgehen: Benutzt man DateTimeFormatter mit dem Formatstring yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z', wird das nicht funktionierende Beispiel tatsächlich korrekt als Sun Nov 26 17:21:03 CET 2023 geparst.

Dieser Formatstring funktioniert natürlich nicht mit SimpleDateFormat. Der finale Test zeigte, dass mit diesem Formatstring auch kürzere Zeitstempel wie etwa 2023-11-27T16:50:00Z erfolgreich und korrekt geparst werden können.

Das ließ nun für mich nur noch einen Schluss zu: Ich werde demnächst damit beginnen, die Klasse SimpleDateFormat langsam aus meiner Codebasis zu entfernen - und damit mir mein Rückenmark (Muskelgedächtnis) später keinen Streich spielt werden ich anschließend mittels -link 2022/archunittests.txt=ArchUnit die Benutzung dieser Klasse auf die schwarze Liste setzen.

Artikel, die hierher verlinken