0.0 ist kein gültiger Zeitstempel

[ASM]

Zitat von Luckie:

Da der Datentyp Date keine Zeitangabe besitzt, wird er, vermute ich mal, nicht durch eine Fließkommazahl repräsentiert, sondern durch einen Integer. Und damit wäre eine Fließkommazahl kein gültiger Date Wert.

Das Thema ist nicht mehr ganz taufrisch, bedarf aber doch deutlicher Korrektur:

Zunächst einiges Grundsätzliche:
Zwar wird der Wert für Date() tatsächlich intern (innerhalb der Funktion TryEncodeDate()) aus der Summe ausschließlich reiner Integerwerte berechnet, er wird aber dennoch eindeutig als Typ TDateTime abgelegt und ist somit de facto vom Typ Double.

So zeigt auch der Code

Code:

showmessage(format('Ausgabewert Date() belegt %d Bytes',[sizeof(date())]));

an, dass der von Date() zurückgegebene Wert tatsächlich 8 Bytes belegt (zur Erinnerung: Integervariablen belegen 4 Bytes)

Von den 8 Bytes einer TDateTime-Variablen werden 4 Bytes für den exponentiellen Anteil, also die Tageszeit verwendet und 4 Bytes für die Mantisse, also das aktuelle Tagedatum, gemäß dem detaillierten Format des Zeitstempels:
Bit Inhalt
-------------------
00-04 Sekunde
05-10 Minute
11-15 Stunde
16-20 Tag
21-24 Monat
25-31 Jahr

Bei Date() werden die Nachkommastellen, welche in TDateTime die Tageszeit definieren, grundsätzlich immer mit 0 belegt.
Dagegen werden bei Time() die Vorkommastellen grundsätzlich immer mit der Bytefolge belegt, die dem Datum 30.12.1899 entspricht, also auf das Datum bezogen ist, welches Delphi seit Delphi 2 als Referenzwert seiner TDateTimezählung verwendet (dies aus Gründen der Kompatibilität zu der zuvor von MS eingeführten OLE 2.0 Automation).

Dementsprechend wirft der Code

Code:

showmessage(format('Date() = %d',[date()]));

die EConvertError-Exception "Format '%d' ungültig oder nicht kompatibel mit Argument",
wogegen der Code

Code:

showmessage(format('Date() = %f',[date()]));

ganz normal ausgibt (am 10.08.2011): "Date() = 40765,00"


Das von Angel4585 beschriebene Problem entsteht nun vielmehr durch einen Bug in der Funktionskette StrToDate() -> TryStrToDate() -> ScanDate() -> ScanNumber(): In ScanNumber() wird die Stringlänge der eingebenen Jahreszahl auf maximal 4 Zeichen gekürzt, sodass eben von der tatsächlich eingegebenen Jahreszahl 11572 nur die gekürzte Jahreszahl 1157 übrigbleibt. Diese aber liegt unterhalb der Referenzjahreszahl 1899 (Wert = 0), wodurch die in TryEncodeDate(Y, M, D, Date) berechnete Date-Variable negativ wird und dadurch letztendlich die beschriebene EConvertError-Exception ausgelöst wird.

Von diesem Problem sind alle Funktionen betroffen, die einen Datumstring in eine TDateTime- bzw. TDate-Variable konvertieren (wie StrToDateTime() und StrToDate()): diese sind also nur für Jahreszahlen bis 9999 einsetzbar!

Interessanterweise ist dem gegenüber als maximaler TDate-Wert 2146790053 erlaubt, was dem Datum 11.Juli 46907 (!) entspricht. Die Konversion eines solch hohen TDate-Wertes in eine Stringvariable ist also von dem o.g. Problem nicht betroffen (obwohl auch hierbei der eigentliche Maxint von 2147483647 nicht erreicht werden kann, allerdings dann keine Exception ausgelöst wird, sondern das Datum oberhalb eines TDate von 2146790053 nur rigoros und ohne Warnung auf 00.00.0000 gesetzt wird).

[Luckie]

Danke, wieder was gelernt.

[Angel4585]

Ganz schön lange Erklärung, danke
Aber eine Frage:

Zitat von ASM:

Das von Angel4585 beschriebene Problem entsteht nun vielmehr durch einen Bug in der Funktionskette StrToDate() -> TryStrToDate() -> ScanDate() -> ScanNumber(): In ScanNumber() wird die Stringlänge der eingebenen Jahreszahl auf maximal 4 Zeichen gekürzt, sodass eben von der tatsächlich eingegebenen Jahreszahl 11572 nur die gekürzte Jahreszahl 1157 übrigbleibt. Diese aber liegt unterhalb der Referenzjahreszahl 1899 (Wert = 0), wodurch die in TryEncodeDate(Y, M, D, Date) berechnete Date-Variable negativ wird und dadurch letztendlich die beschriebene EConvertError-Exception ausgelöst wird.

Von diesem Problem sind alle Funktionen betroffen, die einen Datumstring in eine TDateTime- bzw. TDate-Variable konvertieren (wie StrToDateTime() und StrToDate()): diese sind also nur für Jahreszahlen bis 9999 einsetzbar!

Interessanterweise ist dem gegenüber als maximaler TDate-Wert 2146790053 erlaubt, was dem Datum 11.Juli 46907 (!) entspricht. Die Konversion eines solch hohen TDate-Wertes in eine Stringvariable ist also von dem o.g. Problem nicht betroffen (obwohl auch hierbei der eigentliche Maxint von 2147483647 nicht erreicht werden kann, allerdings dann keine Exception ausgelöst wird, sondern das Datum oberhalb eines TDate von 2146790053 nur rigoros und ohne Warnung auf 00.00.0000 gesetzt wird).

Ich geb die 11572 ja nirgends ein. Es wird über .AsDateTime, Now() eingegeben. Also als Jahr 2011. Dann wird da doch nix abgeschnitten.
Oder hab ich jetzt was falsch verstanden?

[ASM]

Nach den Fakten aus Deiner Beschreibung kann die Deklaration des Feldes in Deiner Tabelle kein numerischer Typ TDate sein, sondern das Feld muss als Typ String vorliegen. Denn wie käme sonst im Feld Deiner Tabelle explizit der Eintrag im Format "dd.mm.yyyy" zustande ? Schließlich ist dieses Format mit einer rein numerischen TDate-, d.h. Double-Variablen, so definitiv nicht möglich, sondern nur als String.

Also wird Deine Eingabe des Datums als Now() zwar zunächst als TDate-Wert angenommen und kann - wie von mir oben beschrieben - intern zur Aufnahme in das Feld dann auch richtig in einen Datumstring umgesetzt werden, selbst wenn die Jahreszahl im String größer als 4 Zeichen werden sollte, wie hier geschehen. Warum jedoch dieser überhöhte Mantissenwert, der zu der Jahreszahl mit mehr als 4 Zeichen führt, bei Dir auftritt, ist aus Deiner alleinigen Angabe, dass Du das Feld über ".AsDateTime auf Now" setzt, nicht nachzuvollziehen. Dazu müsste man die näheren Details zum Code kennen.

Jedenfalls erklärt sich beim anschließenden Wiederauslesen des (String-)Feldeintrages als TDate-Wert die von Dir beobachtete Fehlermeldung exakt aus meiner obigen Erklärung. Denn zwangsläufig muss ja für diesen Vorgang im Hintergrund eine der String->TDateTime-Konversionsroutinen werkeln und somit der Bug aktiv werden.

.

[Angel4585]

Ahhh verstanden Naja da steht im dbd32(Datenbank Explorer) nur Date als Feldtyp ob das dann als String oder Zahl gespeichert wird weis ich natürlich nicht.