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.

[dummzeuch]

Zitat von 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).

Oha, das ist aber optimistisch gedacht.

Selbst aktuelle Datenbanken dürften da noch Probleme machen, da kommt es ggf. darauf an, was der Admin eingestellt hat.

z.B. kennt MS-SQL auch so völlig bescheuerte Formate wie '09-17-20', was man natürlich auf den ersten Blick als amerikanisches Datumsformat (MM/TT/YY) mit '-' statt '/' erkennt. Quasi das schlimmste, was man sich ausdenken kann. Und glaube bloß nicht, dass das keiner so einstellt (Woher wüsste ich das sonst?)

[TigerLilly]

"Jede" sind ziemlich viele
Aber die meisten sollte schon gehen.

SQL 92 ist der Standard, an den die meisten Systeme sich halten:
https://www.ibphoenix.com/resources/...design/doc_169

[Redeemer]

Zitat von 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).

Das Beispiel geht mit MSSQL nicht, denn ein Jahr hat keine 17 Monate. MSSQL akzeptiert das Beispiel ohne Striche als gültiges Datum, MySQL aber nicht. Was bei beiden geht, ist '2020-09-17T16:24:33'.

Bevor das jemand fragt: CURRENT_TIMESTAMP ist die einzige von MySQL und MSSQL akzeptierte Schreibweise für Jetzt.