Verändertes StrToDateTime Verhalten in Delphi 11.3

[OlliWW]

Hallo,

Ich teste nun das neue Delphi 11.3. und ich konnte ein verändertes Verhalten bei der Konvertierung von Strings in DateTime bemerken.

Folgende Strings konvertiere ich mit TryStrToDateTime und vergleiche damit den resultierenden DateTime-Wert und die Antwort der Funktion (True / False):

01.01.2023 25:34:45
Liefert False, was korrekt ist da "25" keine gültige Stunde ist

01.01.2023 12:61:45
Liefert False, was korrekt ist, da "61" keine gültige Minute ist

01.01.2023 12:34:99
Liefert "True", obwohl das keine gültige Sekunde ist. Beim resultierenden DateTime, werden die Sekunden einfach "genullt": 01.01.2023 12:34:00 => Fehler?

01.01.2023 12:34:55
Liefert "True", meiner Meinung nach ist der String auch korrekt, also alles wie es erwartet wird.

01.01.2023 12:34:12:1234567890
Liefert "True", allerdings sind die Sekunden genullt: 01.01.2023 12:34:00 => Fehler?

01.01.2023 12:34:12,1234567890
Liefert "True", allerdings sind die Sekunden genullt: 01.01.2023 12:34:00 => Fehler?

01.01.2023 12:34:12:12
Liefert "True", allerdings sind die Sekunden genullt: 01.01.2023 12:34:00 => Fehler?

01.01.2023 12:34:12,12
Liefert "True", ist meiner Meinung nach auch valide.

Hat jemand ein ähnliches Verhalten bereits gesehen und gibt es dafür einen Workarround oder eine Erklärung? Dass "falsche" Millisekunden Auswirkungen auf die Sekunden haben finde ich schon etwas bedenklich, ebenso wie dass "falsch" Stunden und Minuten nicht interpretiert werden (korrektes verhalten) aber "falsch" Sekunden einfach so durch gehen und "0" liefern.

Viele Grüße

[Redeemer]

Was kommt denn beim letzten davon raus?

Wenn auch da keine Sekunden rauskommen, würde ich vermuten, dass die Methode die Sekunden ignoriert, wenn sie keine valide Angabe vorfindet. TryStrToDateTime sagt klar: Sekunden sind optional. Aber das nicht erst seit Delphi 11.3.

[Uwe Raabe]

Implementiert ist es zumindest so, dass es bei einem Fehler in den Sekunden auf ShortTime Format zurück fällt. Daher die 00 Sekunden.

Aber ich hätte bei einem ungültigen String auch ein False erwartet und sehe das aktuelle Verhalten durchaus als diskutabel an. Mach doch mal einen QP Report auf, dann werden wir ja sehen on das Absicht ist.

[Jasocul]

Du schreibst, dass das ein verändertes Verhalten ist, stellst aber nicht gegenüber, zu welcher Version ind wie dort das Verhalten ist.
Grundsätzlich ist das Verhalten diskussionswürdig, aber ohne zu wissen, wie es vorher war, fehlt eine wichtige Grundlage. Natürlich kann das jeder selbst ausprobieren, aber ... nee.

[himitsu]

[Post deleted]

add: neee nee, ich bin mir ganz sicher, dass ich vorhin noch richtig war

[Uwe Raabe]

Zitat von himitsu:

Es gibt Zertifikate

Falscher Thread?

[OlliWW]

Ich habe nun mal in aller Ausfürhlichkeit ein paar Tests gemacht mit TryStrToDateTime in Delphi 10.4., 11.1. und 11.3.

Das Verhalten zwischen den ersten beiden und der aktuellsten Version ist definitiv anders.

Hier sieht man links den Input. Rot bedeutet das result ist "false", grün bedeutet das result ist true und der Wert entspricht dem erwarteten Wert. Gelb bedeutet es kommt zwar true zurück, aber das Verhalten ist nicht das erwartete.

Ich habe ein entsprechendes Ticket bei Embarcadero aufgemacht, ich bin mir ziemlich sicher, dass dies ein Fehler ist.

[Uwe Raabe]

Zitat von OlliWW:

Ich habe ein entsprechendes Ticket bei Embarcadero aufgemacht, ich bin mir ziemlich sicher, dass dies ein Fehler ist.

Ein Support-Ticket oder einen QP-Eintrag? Bei letzterem hätten wir hier gern die Nummer.

[jaenicke]

Das ist der neue Report:
https://quality.embarcadero.com/browse/RSP-40711

Vorher wurden mit Delphi 11 diverse andere Einträge als erledigt geschlossen. Kommentar von Dmitry Arefiev:

Zitat:

Before v11 the StrToDateTime was less strict checking format string and input data. In v11 it offers greater flexibility (more formats are supported), and more strict checking.

[Jasocul]

@OlliWW:
Danke für die Übersicht