TDate enthält Uhrzeit?

[Iwo Asnet]

Es ist schon etwas schwer, eine Begründung dafür zu liefern, das ein Wert vom Typ 'TDate' auch eine Uhrzeit enthält, ein Wert vom Typ 'TTime' auch das Datum und 'TDateTime' beides. Weiterhin ist es nicht leicht, die Existenz der drei Datentypen zu rechtfertigen, wo es einer genauso täte.

Das das so ist, scheint nun jeder begriffen zu haben, aber klar im Sinne von 'klarer Code' ist das mit Sicherheit nicht, eher das Gegenteil.

Verwirrend.

:freak:

[Bummi]

Delphi-Quellcode:

type
  TDateOnly= class(TInterfacedObject)
    private
      FValue:Double;
    procedure SetValue(const Value: Double);
    Property value:Double Read Fvalue Write SetValue ;
  End;


implementation

{$R *.dfm}
procedure TDateOnly.SetValue(const Value: Double);
begin
  Fvalue := Trunc(Value);
end;



procedure TForm5.Button1Click(Sender: TObject);
var
 d:TdateOnly;
begin
   d.value := now;
   Showmessage(DateTimeToStr((d.value)));
end;

[CCRDude]

Zitat:

Zitat von Iwo Asnet (Beitrag 1180462)

Das das so ist, scheint nun jeder begriffen zu haben, aber klar im Sinne von 'klarer Code' ist das mit Sicherheit nicht, eher das Gegenteil.

Interessanterweise ist das für mich eben gerade ein Beispiel von klarem Code. "Eigentlich" gibt es nur ein TDateTime, um aber für einige Aufgaben zumindest deklaratorisch klarzumachen, was ein spezieller Wert enthält, wird der Name angepasst. Klar, das könnte auch über den Namen der Variablen passieren, aber sowas findet sich doch häufiger... diverse Bibliotheken definieren sich ihre eigenen Stringtypnamen, die auch "identisch" mit den normalen sind. Oder wir alle haben schonmal ne MeineUnitException = class(Exception) ohne mehr dran verwendet, oder?

Zitat:

Zitat von Iwo Asnet (Beitrag 1180462)

Es ist schon etwas schwer, eine Begründung dafür zu liefern, das ein Wert vom Typ 'TDate' auch eine Uhrzeit enthält,

Und das ist dann eben "Schuld" des Programmierers. Da ist der Wert extra schon als ''TDate'' deklariert, und der Kerl weist auch ne Uhrzeit zu... ;)

[uligerhardt]

Zitat:

Zitat von Iwo Asnet (Beitrag 1180462)

Es ist schon etwas schwer, eine Begründung dafür zu liefern, das ein Wert vom Typ 'TDate' auch eine Uhrzeit enthält, ein Wert vom Typ 'TTime' auch das Datum und 'TDateTime' beides. Weiterhin ist es nicht leicht, die Existenz der drei Datentypen zu rechtfertigen, wo es einer genauso täte.

Ich vermute mal, die Typen sind dafür gut, dass man im OI unterschiedliche Property-Editoren anbieten kann.

[bwolf]

Zitat:

Zitat von Uwe Raabe (Beitrag 1180452)

Es gibt schon einen Unterschied. Deklariert man eine Methode á la

Delphi-Quellcode:

(var: Value: TDate)

, so kann man keinen TDateTime als Parameter übergeben, da die Typen nicht übereinstimmen.

hm doch genau das funktionert ja - was mich auch dazu veranlasst hatte diesen Thread hier zu eröffnen.

Code:

procedure Test(ADate : TDate);
begin
  showmessage(DateTimeToStr(ADate));
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  d : TDateTime;
begin
  d := Now;
  Test(d);
end;

[uligerhardt]

Zitat:

Zitat von bwolf (Beitrag 1180478)

Zitat:

Zitat von Uwe Raabe (Beitrag 1180452)

Es gibt schon einen Unterschied. Deklariert man eine Methode á la

Delphi-Quellcode:

(var: Value: TDate)

, so kann man keinen TDateTime als Parameter übergeben, da die Typen nicht übereinstimmen.

hm doch genau das funktionert ja - was mich auch dazu veranlasst hatte diesen Thread hier zu eröffnen.

Code:

procedure Test(ADate : TDate);
begin
  showmessage(DateTimeToStr(ADate));
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  d : TDateTime;
begin
  d := Now;
  Test(d);
end;

Du hast das

Delphi-Quellcode:

var

vor Value übersehen. (Den Doppelpunkt darfst du gerne weglassen. :mrgreen:)

[Furtbichler]

Zitat:

Zitat von CCRDude (Beitrag 1180475)

Interessanterweise ist das für mich eben gerade ein Beispiel von klarem Code.

Also in meinen Augen sollte ein Datentyp mit dem Namen 'TDate' ein Datum enthalten, sonst nichts. Analog sollte ein 'TTime' eine Uhrzeit repräsentieren. Alles andere ist verwirrend.

Nach deiner Sichtweise könnten wir auch mit einem einzigen Zahlentyp aufwarten: 'TNumber', denn es ist ja die Schuld des Programmierers, wenn der Code dadurch nicht klar genug ist. Ich kann deine Sichtweise nachvollziehen, aber die Schlußfolgerung ist imho falsch.

Zitat:

Zitat von CCRDude (Beitrag 1180475)

diverse Bibliotheken definieren sich ihre eigenen Stringtypnamen, die auch "identisch" mit den normalen sind. Oder wir alle haben schonmal ne MeineUnitException = class(Exception) ohne mehr dran verwendet, oder?

Diese Datentypen sind ja auch von der Bedeutung her identisch

Zitat:

Und das ist dann eben "Schuld" des Programmierers. Da ist der Wert extra schon als ''TDate'' deklariert, und der Kerl weist auch ne Uhrzeit zu... ;)

Unglaublich. Bei richtigen Programmiersprachen meckert hier der Compiler. Merkste was? ;-)


Ich verlange von meinen Datentypnamen, das das draufsteht, was drin ist. Nicht mehr und nicht weniger.

TDate, TTime und TDateTime sollten nicht zuweisungskompatibel sein, denn ein TDateTime ist genaugenommen ein genauer Zeitpunkt (innerhalb der bekannten Grenzen), während ein TDate einfach nur ein Datum und TTime nur eine Zeit darstellen sollte.

Desweiteren ist bei diesem Datentyp nicht zu vermitteln, wie die Differenz zwischen zwei Zeitpunkten wieder ein Zeitpunkt sein kann, das ist bescheuert und schlicht und ergreifend falsch. Genauso hirnrissig wie z.B. die Differenz zwischen zwei Temperaturangaben wieder als Temperatur anzugeben. Zwischen 5°C und 20°C liegen eben nicht 15°C sondern 15 K.

Delphi halt. Pragmatik und zum-frickeln-einladend-praktisch kommt vor OOP. Das macht den jedoch Charme der Sprache aus.

[jfheins]

Zitat:

Zitat von Furtbichler (Beitrag 1180549)

Desweiteren ist bei diesem Datentyp nicht zu vermitteln, wie die Differenz zwischen zwei Zeitpunkten wieder ein Zeitpunkt sein kann, das ist bescheuert und schlicht und ergreifend falsch.

Ja, daher gibt es in anderen Programmiersprachen ja auch einen TimeSpan-Typ. Übrigens auch in Delphi :mrgreen:

Zitat:

Genauso hirnrissig wie z.B. die Differenz zwischen zwei Temperaturangaben wieder als Temperatur anzugeben. Zwischen 5°C und 20°C liegen eben nicht 15°C sondern 15 K.

Da kann ich dir aber nicht Recht geben. Auf quasi jeder Skala (inkl. Temperatur) ergibt die Differenz zweier Werte wieder einen Wert mit der gleichen Einheit. 10m minus 2m sind eben 8m.
Genau so ist eine Differenz von 15°C gleich einer Differenz von 15K, die Einheiten sind ja gleich groß. Ich habe jetzt schon ein paar Minuten nachgedacht und die Zeit ist die einzige Skala, wo so markant zwischen Zeitpunkten und Zeiträumen unterschieden wird...

[Furtbichler]

Zitat:

Zitat von jfheins (Beitrag 1180550)

Ja, daher gibt es in anderen Programmiersprachen ja auch einen TimeSpan-Typ. Übrigens auch in Delphi :mrgreen:

Toll, seit wann? Hab nur BDS2006. Und dann ist die Differenz zwischen zwei TDateTime-Werten .... doch wieder ein TDateTime :mrgreen:

Zitat:

Zitat von jfheins (Beitrag 1180550)

Da kann ich dir aber nicht Recht geben.

Solltest Du aber:
http://de.wikipedia.org/wiki/Grad_Celsius

Zitat:

Ich habe jetzt schon ein paar Minuten nachgedacht...

Gib Dir ein wenig mehr Zeit.

Nachtrag:

Zitat:

Zitat von jfheins (Beitrag 1180550)

die Zeit ist die einzige Skala, wo so markant zwischen Zeitpunkten und Zeiträumen unterschieden wird...

Nachdem ich kurz nachgedacht habe, fallen mir noch z.B. "Orte" ein. Das ist zwar ein mehrdimensionaler Wert, aber die Differenz zweier Orte (im Raum), aka Entfernung wäre ein weiteres Beispiel.

[jfheins]

Ich zitiere mal aus dem Link:

Zitat:

Als Einheit für Temperaturdifferenzen wird das Kelvin [...] empfohlen, [...] darf die Differenz zweier Celsius-Temperaturen auch in der Einheit Grad Celsius (°C) angegeben werden.

Das klingt jetzt nicht besonders eindeutig.

Das mit der Entfernung ist so ne Sache. Wenn ich sage "Fulda ist 100km entfernt und Würzburg 200km" dann hat die Differenz auch wieder die Einheit km.
In C# gibt es ja Point und Size und ich habe da auch schon ein paar Mal konvertiert - vornehmlich von Size zu Point ;)