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. :wink:

[himitsu]

[Post deleted]

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

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1519416)

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:

Zitat von OlliWW (Beitrag 1519599)

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

[OlliWW]

Zitat:

Zitat von jaenicke (Beitrag 1519602)

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.

Hm, also wenn man vorher "falsche" Sekundenwerte eingegeben hat, kam ein "False" und nun kommt ein True - ich weiß nicht ob die Aussage von Embarcadero so zu trifft, dass nun genauer hingeschaut wird, bei dem Input string :lol:
Komischerweise ist der Sprung ja auch innerhalb der v11 Version passiert.

Ich denke dabei an Tools die aus einer CSV Messwerte importieren zum Beispiel. Wenn auf einmal Sekunden auf "00" konvertiert werden, halte ich das eher für einen Bug als ein Feature. Aber schauen wir mal was Embarcadero dazu sagt. Auf der einen Seite hatten wir glücklicherweise Unit-Tests die uns auf dieses "Feature" hingewiesen haben zum anderen mussten wir nun viel Code umschreiben / absichern :(

[Der schöne Günther]

Zitat:

Zitat von OlliWW (Beitrag 1519606)

Auf der einen Seite hatten wir glücklicherweise Unit-Tests die uns auf dieses "Feature" hingewiesen haben zum anderen mussten wir nun viel Code umschreiben / absichern

Geht mir auch so - Bin immer wieder froh, wie viele Verhaltensänderungen in der RTL meine Unit-Tests nach einem Delphi-Update finden. Stellt euch mal vor, Embarcadero hätte auch welche 🙄

Nein, die haben bestimmt welche, aber ganz ganz sicher nicht genug. Wir haben mittlerweile etliche Unit-Tests welche ganz grundlegende Dinge in der RTL hinterfragen (Stringlisten und so). Sollte wirklich nicht notwendig sein, so etwas.

[Rolf Frei]

Werden die ms nicht mit einem Punkt abgetrennt? Ist das bei euch in Deutschland anderst als im Rest der Welt? Windows bietet hiefür auf jeden Fall kein spezielles Zeichen bereit, zumindest nicht in den Regionseinstellungen, und nach ANSI Norm muss das ein Punkt sein. So zumindest müssten doch die Stringwerte mit Millisekunden ein richtiges Resultat liefern.

Aber grundsätzlich bin ich da auch der Meinung, dass das so nicht sein darf, da nun vorher funktionierender Code nicht mehr richtig funktioniert und falsche Resultate liefert. Dieses Verhalten müsste optional sein.

[Uwe Raabe]

Ich sehe das ähnlich. Eine striktere Umwandlung bedeutet ja nicht, dass man gerade mal soviel von dem liest, das noch eine korrekte Umwandlung ermöglicht und alles folgende ignoriert. Unter strikt verstehe ich, dass ein String einen gültigen Datum/Zeit-Wert darstellt und nicht mehr. Ein in den früheren Versionen ungültiger String sollte auch jetzt noch False liefern. Allerdings kann es durchaus sein, dass ein früher True liefernder String nun unter strikter Auslegung ein False liefert, was ja auch beabsichtigt wäre.

[Jasocul]

Würde bei denen, die True liefern dann auch StrToDateTime einen "gültigen" Wert zurückliefern?
Ich würde es ja selbst prüfen, habe aber kein D11.3

[OlliWW]

Zitat:

Zitat von Jasocul (Beitrag 1519619)

Würde bei denen, die True liefern dann auch StrToDateTime einen "gültigen" Wert zurückliefern?
Ich würde es ja selbst prüfen, habe aber kein D11.3

Siehe meine Tabelle auf der ersten Seite dieses Threads.
Die Antwort ist "Jein", es liefert ein Datum zurück, allerdings obwohl der Sekunden-Teil syntaktisch und semantisch korrekt ist, werden die Sekunden auf "00" gestellt - was meiner Meinung nach ein inhaltlicher Fehler ist.

[Sherlock]

Geb es da nicht mal ein Projekt in dem Delphi Anwender Unittests für die RTL, VCL etc. geschrieben hatten? Ich such mir grad nen Wolf und stolper nur über tonnenweise HowTos zu Unittests.

Sherlock

[Der schöne Günther]

Ich glaube Nick Hodges hatte damals damit angefangen, ein paar Leute sind mitgezogen "Open Source Delphi RTL Unit Tests" zu machen, aber das verlief relativ schnell im Sand da Embarcadero kein Interesse daran hatte, selbst mitzumachen.

[Sherlock]

Ja, das hab ich auch noch so im Kopf...ich hatte nur Hoffnung auf mehr. Kann fast nicht glauben, daß viele vor ihrem Delphi sitzten und zumindest Dutzendfach das gleiche gemacht wird.

:(

Sherlock

[Uwe Raabe]

Guckst du hier: https://github.com/UweRaabe/Delphi-Unit-Tests. Es gibt auch noch eins von Nick Hodges, aber das hat keine Contributors.

Angeblich wird das auch von Embarcadero überwacht, aber es tut sich halt auch recht wenig dort.