Welches DateTime Format schluckt jede Datenbank?

[t2000]

Hallo,

wie der Titel schon sagt, welches DateTime Format schluckt jede Datenbank?
Ich habe für ein Programm eine kleine Installationsdatei, in der auch SQL-Befehle stehen. In diesen Befehlen taucht auch ein Datum/Uhrzeit auf.
Gibt es eine Norm, mit der ich ein ==> INSERT INTO Tabelle (Feld1, Feld2, Feld3) VALUES (12, 'Ein Text', '25.04.2020 15:33:44') <== machen kann?
'2020-04-25T10:58:00.000' vielleicht? ISO-Norm

Gruß Thomas

[Der schöne Günther]

Um Gottes Willen bitte keine Strings zusammenbasteln sondern mit Parametern.

Dann kommt in den Parameter einfach deine DateTime-Variable und du musst dir keinen Kopf machen.

Vor allem wegen Dingen wie "SQL Injection" sollte man auf keinen Fall Strings zusammenbauen sondern mit Parametern arbeiten. Hier einmal ein anschauliches und unterhaltsames Beispiel:
https://xkcd.com/327/

[t2000]

Zitat von Der schöne Günther:

Um Gottes Willen bitte keine Strings zusammenbasteln sondern mit Parametern.

Dann kommt in den Parameter einfach deine DateTime-Variable und du musst dir keinen Kopf machen.

Vor allem wegen Dingen wie "SQL Injection" sollte man auf keinen Fall Strings zusammenbauen sondern mit Parametern arbeiten. Hier einmal ein anschauliches und unterhaltsames Beispiel:
https://xkcd.com/327/

Nein, nein. Alles Bekannt.
Es geht hier nicht um Delphi, sondern um ein ganz kleines Importskript, das bei der Installation der Software vorher eingespielt werden soll.

Quasi direkt nach dem CREATE TABLE ...

[Delphi.Narium]

Zitat von Der schöne Günther:

Um Gottes Willen bitte keine Strings zusammenbasteln sondern mit Parametern.

Dann kommt in den Parameter einfach deine DateTime-Variable und du musst dir keinen Kopf machen.

Vor allem wegen Dingen wie "SQL Injection" sollte man auf keinen Fall Strings zusammenbauen sondern mit Parametern arbeiten. Hier einmal ein anschauliches und unterhaltsames Beispiel:
https://xkcd.com/327/

Das funktioniert aber nicht in 'ner Installationsdatei, die u. a. auch Insertstatements enthält.

Man baut nicht jede Datenbank mit 'nem Delphiprogramm auf, in dem man Parameter nutzen kann. Es gibt auch immer noch Installationsscripte für Datenbanken, die neben den Createstatements für die Tabellen, Indizies, ..., auch Insertstatments für die erstmalige Befüllung enthalten.

Und in dem Zusammenhang ist die Frage nach dem zu verwendenden Datumsformat durchaus berechtigt.

Geht dashier bei allen Datenbanken? W3Schools - SQL Working With Dates

Und nu: Schauen, was alle anderen ggfls. zu verwendenden Datenbanken so unterstützen.

Hab' auf die Schnelle keine Seite gefunden, die da mal 'nen "globalgalaktischen" Überblick zur Verfügung stellt.

[HeZa]

Zitat von Delphi.Narium:

...Geht dashier bei allen Datenbanken? W3Schools - SQL Working With Dates...

Ein Datum mit Uhrzeit im ISO-Format sollten eigentlich viele Datenbanken schlucken können (z.B. 2020-09-17 16:24:33).

[jobo]

Alle? Das ist schon eine krasse Frage.

Auch wenn DB vielleicht ISO Norm Formatierungen abdecken können, machen sie es gerne unterschiedlich. Also per Funktion die überall anders genannt wird. Ich bin ehrlich gesagt noch nicht drauf gekommen, sowas zu versuchen. Mein Tipp wäre, dass ein Datum entsprechend der Windows Datumseinstellungen als bloßer Text formatiert am besten geht. Das Script würde dann mit impliziter Typkonvertierung beim Datum arbeiten.
Das Problem daran ist natürlich sofort klar, niemand weiß vorher, wie alle Nutzer ihre Windows Datumsformatierung eingestellt haben.

Wenn man das durchspielt, landet man irgendwann bei einem Importprogramm, das wie bereits beschrieben das Typhandling selbst macht und ein festes, proprietäres Datum vorgesetzt bekommt.

[Delphi.Narium]

Deshalb weiter oben auch meine Frage

Zitat:

Geht dashier bei allen Datenbanken?

Zitat von HeZa:

Ein Datum mit Uhrzeit im ISO-Format sollten eigentlich viele Datenbanken schlucken können (z.B. 2020-09-17 16:24:33).

Das sollte eigentlich wäre eine wünschenswerte Annahme, aber ich gehe mal davon aus, dass das leider wohl für die nächsten Jahr(zehnt)e Wunschdenken bleibt.

FireBird kennt keinen Datentypen DateTime, sondern nur Date, Time und Timestamp.

Postgres kennt wohl auch Date, Time und Timestamp, wobei der Timestamp von PostGres 14stellig ist und bis zu einer Auflösung von einer Microsekunde geht. Bei FireBird ist es jedoch ein aus zwei 32-bittigen Teilen bestehendes Konstrukt, für die getrennte Aufnahme von Datum und Uhrzeit, mit 'ner Auflösung bis zur einer Millisekunde.

Oracle hat sowas wie Date und Timestamp.
Timestamp gibt es mit oder ohne Zeitzone oder auch lokaler Zeitzone.

Je nach gewähltem Typ könnte man daher bei 'nem

Code:

INSERT INTO Tabelle (Feld1, Feld2, Feld3) VALUES (12, 'Ein Text', '25.04.2020 15:33:44')

beim Auslesen durchaus was unterschiedliches bekommen.

Daher ist Timestamp <> Timestamp

Bei Access ist DateTime 8bittig vom Jahr 100 bis zum Jahr 9999.

MySQL kennt DateTime und Timestamp, sie können beide Datum und Uhrzeit enthalten, haben aber unterschiedliche "Zeitspannen" für gültige Werte. Bei 'nem Insert muss man da damit rechnen, dass der Wert aus Values mit der gerade im System eingestellten Zeitzone Richtung UTC "konvertiert" wird.

Man sollte beim Insert die Zeitzone also auch noch berücksichtigen ...

Und es wird bestimmt auch noch weitere Datenbanken geben, die was eigenes haben und Systemeinstellungen auf eigene Weise berücksichtigen, ...

Von daher befürchte ich: Die Frage

Zitat:

Welches DateTime Format schluckt jede Datenbank?

kann man nicht ruhigen Gewissens mit einer einfachen Datumsformatangabe beantworten.

[HeZa]

Er fragte nach der Datums/Zeit-Formatierung. Den richtigen Datentyp zu wählen überlasse ich dem Fragesteller.

[himitsu]

Ja, im Delphi den Typ in DateTime/TimeStamp/... konvertieren und die DB-Komponenten es machen lassen ist das Einfachste und Universellste.

In diesem Fall mach es dir einfach und füge eine Funktion ein
oder arbeite bei den Datumstypen mit "eigenen" VARCHAR->Datumstyp-AutoCasts (CREATE CAST o.Ä.).
INSERT INTO Tabelle (Feld1, Feld2, Feld3) VALUES (12, 'Ein Text', DeineFunktion('25.04.2020 15:33:44'))
Alles was nicht allgemeingültig ist, wird mit jeweils Manuellen und AutoCasts versehen und lässt sich so zentral anpassen, an nur einer Stelle.

Oder mache den Imports/Export diese Typen als VARCHAR, wo dann, anschließend an den Import, diese Spalten erst mit jeweils passenden Methoden konvertiert/umkopiert werden.


Ja, Postgres kennt Vieles und Alles auch nochmal mit frei definierbarem Rundungsverhalten (quasi mit änderbarer Bittigkeit)
und dann auch nochmal mit oder ohne TimeZone, welche im Typ gespeichert/verwaltet werden könnte.
Dazu verstehen die vorhandenen AutoCasts auch noch mehrere Text-Formate. (Datenbank/Tabelle/Feld auf Deutsch versteht ein deutsches Datumsformat und auch unterschiedliche ISO-Formate, was aber z.B. in einer englischen Datenbank importiert knallen dürfte)

[t2000]

Das habe ich fast befürchtet. Keinerlei allgemeingültige Regel.
Ich werde wahrscheinlich das Installationsskript für die (für uns) zur Zeit wichtigsten Datenbanken (PostgreSQL, MSSQL, evtl. SQLite, Interbase) für Standardnutzer in Deutschland anpassen. Da komme ich mit einer einzigen Formatierung klar.
Solange ich nicht Software für das Ausland produziere kann ich die wenigen Ausnahmefälle wohl von Hand bearbeiten.
MSSQL macht zum Beispiel beim Generieren von Importskripten immer sowas: INSERT ... VALUES(12, 'abc', cast('25.04.2020 14:55:22' as DateTime2))
wobei ja dann der Datentyp bekannt sein müssete