Negative TDateTime-Werte

[Codehunter]

Hallo zusammen!

In meiner Anwendung wird viel mit TDateTime gearbeitet. Für interne Zwecke habe ich eine INVALID_DATE = 100 Konstante eingeführt, damit ich NULL-Werte innerhalb der DB in TDateTime abbilden kann. Ein INVALID_DATE = 0 hat sich als fehleranfällig herausgestellt, weil ein nicht initialisierter TDateTime auch = 0 ist.

Weil TDateTime bei ~ 1900 beginnt, bei uns aber keine Werte vor 1980 realistisch sind, habe ich 100 als INVALID_DATE gewählt, was dem 9.4.1900 entspricht. Allerdings frage ich mich ob ex vllt. klüger wäre, stattdessen -100 zu nehmen.

Eure Meinung?

Grüße
Cody

[DieDolly]

Rein rechnerisch sind beide Werte gleich anfällig.
Wenn irgendwas falsch gerechnet wird und ein Datum für 100 oder -100 rauskommt, stehst du vor dem selben Problem.

Das ist aber höchst unwahrscheinlich. Ich würde -100 nehmen.

[freimatz]

Wie wäre es mit NaN?

Was bedeuetet bei dir invalid? Ist ein nicht initialisierter TDateTime nicht auch invalid? Wo ist der Unterschied?

[Schokohase]

Warum nicht einen Nullable<TDateTime> nehmen?

Sowas gibt es bei Spring4D.

Und bevor das Geschrei wieder laut wird (zu groß, zu was weiß ich), das kann man auch per copy-paste in eine eigene Unit schieben und schon ist es nicht mehr (gefühlt) zu groß.

[Der schöne Günther]

Wollte ich auch grade sagen. Mit solchen magische Konstanten wird man nie glücklich. Jeder muss sie kennen und richtig einsetzen. Und so ein Nullable<T> ist ja trivial genug (solange es nur ein TDateTime und z.B. kein TObject ist) um es sich grade selbst zusammenzukloppen.

Wenn eine dumme Datenbank nullbare Werte haben kann, dann sollte deine Hightech-Anwendung 😎 das auch können.

[DieDolly]

An der Stelle würde ich lieber auf die null-Typen von Delphi warten die in 20 Jahren kommen sollen statt irgendwas von Spring4D zu nehmen.

[TigerLilly]

Zitat von Schokohase:

das kann man auch per copy-paste in eine eigene Unit schieben und schon ist es nicht mehr (gefühlt) zu groß.

Das ist aber nicht die feine Art. Use it or leave it. But don´t steal it.

[Schokohase]

Zitat von TigerLilly:

Zitat von Schokohase:

das kann man auch per copy-paste in eine eigene Unit schieben und schon ist es nicht mehr (gefühlt) zu groß.

Das ist aber nicht die feine Art. Use it or leave it. But don´t steal it.

Aber ohne eine Funken Ahnung Leute anhupen ist die feine Art?

Apache-Lizenz

Zitat:

• Man darf Software unter dieser Lizenz frei in jedem Umfeld verwenden, modifizieren und verteilen.
• Änderungen am Quellcode der unter der Apache-Lizenz stehenden Software müssen nicht zum Lizenzgeber zurückgeschickt werden.
• Eigene Software, die unter Apache-Lizenz stehende Software verwendet, muss nicht unter der Apache-Lizenz stehen.

[Rollo62]

Zitat von freimatz:

Wie wäre es mit NaN?

Was bedeuetet bei dir invalid? Ist ein nicht initialisierter TDateTime nicht auch invalid? Wo ist der Unterschied?

Generell, nicht nur für DateTime:
Ich bin mittlerweile auch ein Freund von NaN geworden, und baue meine Rountinen nach und nach
auf "NaN" und "Infinity" Sicherheit aus.
Diese Konstanten sind ja per System vorgegeben, und sollten eindeutig sein.

Ansonsten ist aber auch Spring4D eine überzeugenden Lösung.

[Codehunter]

NaN scheidet aus, denn der ist auch nur wieder 0.0 und damit bei TDateTime = 30. Dezember 1899 12:00 Uhr. Und JA, nicht initialisiert und INVALID sind in meinem Fall zweierlei. Das ist aber sehr fallspezifisch.

Zitat von Uwe Raabe:

Ein TDateTime ist als gültig definiert zwischen dem 01.01.0001 und dem 31.12.9999. Alles andere kann als NULL-DateTime verwendet werden.

Den Tag vor dem 01.01.0001 bekommt man übrigens mit -DateDelta erreichen. Ein solches Datum wird dann von DateTimeToStr als 00.00.0000 dargestellt.

Das ist interessant. Wusste ich auch noch nicht. Ebenso wie die Hilfe, die kennt "DateDelta" auch nicht. Dann wäre ein wirklich INVALIDer Wert INVALID_DATE = -DateDelta - 1 ?