Hallo Gunnar Bittersmann,

das sieht zumindest partiell nach JSON aus und JSON kennt keine anderen Typen als Number und String. Date() ist es egal, ob da ein T steht oder nicht.

Aber ja, ein RFC 9557-konformer String mit dem T zwischen Datum und Zeit wäre grundsätzlich besser. Wenn die DB den nicht liefert, sollte man es serverseitig, wie Felix empfahl, hinbiegen.

Was ich übersehen hatte: Die datetime-Eigenschaft sollte einen Zonenoffset mitbekommen oder gleich als UTC geschickt werden, andernfalls gibt's einmal pro Herbst Rätselraten, ob es jetzt 02:30 Uhr Sommer- oder Winterzeit ist. Mein Solarwechselrichterhersteller macht so einen Scheiß, und für meine Trackingdatenbank muss ich prüfen, ob die CSV-Datei von jetzt auf gleich eine Stunde rückwärts springt, um das verarbeiten zu können. Im Frühjahr ist's wurscht…

Warum daten2 mit Komma kommt, ist tatsächlich merkwürdig. Wurde da ein numerischer Wert im deutschen Locale als String in der Datenbank abgelegt, anstatt ihn für die Speicherung in einen geeigneten Datentyp zu überführen?

'15.8.2005' als falsch zu bezeichnen halte ich für übertrieben. Es ist nicht DIN-konform, nehme ich an, aber FALSCH wäre sowas wie "10-8-2005", was man mit einem M-D-Y Format verwechseln kann.

Oder anders gesagt: Diese DB ist mutmaßlich ein Sanierungsfall, um nicht ständig unsauberen Daten hinterher programmieren zu müssen.

Rolf