0.0 ist kein gültiger Zeitstempel

[Angel4585]

Ich hab ne leere Tabelle mit ein paar Feldern. Eins davon ein Datumsfeld(Nicht DateTime, sondern Date)
Da ich jetz nix besseres gefunden hab, sprich ich das Feld über .AsDateTime an um den Wert auf Now zu setzen.
Dummerweise hab ich jetz als Datum den 15.8.11572 drin und bekomm beim Auslesen als Datetime eben die Meldung 0.0 ist kein gültiger Zeitstempel.
Wenn ich das Feld auf DateTime setze geht es.

Was für Werte erwartet denn so ein Date-Feld?

[DeddyH]

Welche DB ist das denn? Paradox?

[QuickAndDirty]

Zitat von Angel4585:

Ich hab ne leere Tabelle mit ein paar Feldern. Eins davon ein Datumsfeld(Nicht DateTime, sondern Date)
Da ich jetz nix besseres gefunden hab, sprich ich das Feld über .AsDateTime an um den Wert auf Now zu setzen.
Dummerweise hab ich jetz als Datum den 15.8.11572 drin und bekomm beim Auslesen als Datetime eben die Meldung 0.0 ist kein gültiger Zeitstempel.
Wenn ich das Feld auf DateTime setze geht es.

Was für Werte erwartet denn so ein Date-Feld?

Wir haben wegen dieser problem immer nur datetime felder in der BDE benutzt.

[Angel4585]

Ja genau Paradox, ich werds auch auf Datetime umstellen aber interessieren würds mich schon.

[FredlFesl]

Ich hab bisher immer Probleme mit 'Date' gehabt, egal mit welcher DB ich gearbeitet habe. Inzwischen denke ich gar nicht mehr daran, 'Date' zu verwenden.

Inzwischen fühlt sich mein Haar viel kräftiger an.

[Luckie]

Na ja, unter Delphi ist ein DateTime Wert ein Fließkommawert. Der ganzzahlige Anteil repräsentiert den Tag und der Nachkommaanteil den Bruchteil eines Tages, also die Zeit. 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.

[Angel4585]

Verstehe. Und beschreiben klappt weil am Anfang 0 drinsteht was auch als DateTime interpretiert werden kann.
Dann schreibt man ne Fliesskommazahl rein die die Bits weis Gott wie belegt.
Diese Anordnung von Bits wird ab dann beim Auslesen als Integer interpretiert und ergibt so ein Datum.

[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).