AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

TDate enthält Uhrzeit?

Ein Thema von bwolf · begonnen am 29. Aug 2012 · letzter Beitrag vom 30. Aug 2012
Antwort Antwort
CCRDude

Registriert seit: 9. Jun 2011
678 Beiträge
 
FreePascal / Lazarus
 
#1

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 14:23
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?

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...
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#2

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 19:20
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.

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.

Geändert von Furtbichler (29. Aug 2012 um 19:24 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jfheins
jfheins

Registriert seit: 10. Jun 2004
Ort: Garching (TUM)
4.579 Beiträge
 
#3

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 19:31
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
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...
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#4

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 19:40
Ja, daher gibt es in anderen Programmiersprachen ja auch einen TimeSpan-Typ. Übrigens auch in Delphi
Toll, seit wann? Hab nur BDS2006. Und dann ist die Differenz zwischen zwei TDateTime-Werten .... doch wieder ein TDateTime

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

Geändert von Furtbichler (29. Aug 2012 um 19:45 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jfheins
jfheins

Registriert seit: 10. Jun 2004
Ort: Garching (TUM)
4.579 Beiträge
 
#5

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 20:19
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
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#6

AW: TDate enthält Uhrzeit?

  Alt 29. Aug 2012, 22:58
Das klingt jetzt nicht besonders eindeutig.
Ich habe es in der Schule so gelernt, aber im Artikel steht, das die Einheit °C als Differenz auch akzeptabel ist: Also gibst Du mir doch Recht und liegst gleichzeitig auch nicht daneben. Da freuen wir uns jetzt.

Die Angabe von Orten wird nicht in Längeneinheiten angegeben, ihre Entfernung schon.
Bei der Zeit, die ja auch eine Dimension ist, unterscheiden wir auch zwischen dem Zeitpunkt (=fester Ort) und dem Abstand (=Entfernung), beide Angaben werden mit unterschiedlichen Einheiten angegeben, was logisch ist, denn die Orte sind mehrdimensional, deren Entfernung jedoch nicht.

Den Rest deiner Ausführungen (Point, Size, Entfernung) verstehe ich nicht.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.599 Beiträge
 
Delphi 12 Athens
 
#7

AW: TDate enthält Uhrzeit?

  Alt 30. Aug 2012, 10:27
Die Angabe von Orten wird nicht in Längeneinheiten angegeben, ihre Entfernung schon.
Bei der Zeit, die ja auch eine Dimension ist, unterscheiden wir auch zwischen dem Zeitpunkt (=fester Ort) und dem Abstand (=Entfernung), beide Angaben werden mit unterschiedlichen Einheiten angegeben, was logisch ist, denn die Orte sind mehrdimensional, deren Entfernung jedoch nicht.
Wenn du die Entfernung zwischen zwei Orten als Längenangabe verstehst, dann wendest du auf die Differenz der Ortskoordinaten eine Metrik an, die diese Differenz im jeweiligen Koordinatensysten (kartesisch, sphärisch, geodätisch) auf eine Längeneinheit abbildet. Bei eindimensionalen Systemen ist diese Metrik meistens synonym mit dem Absolutwert der Differenz. Wenn du aber bei der Differenz zweier Zeitpunkte auch negative Ergebnisse zulässt, betrachtest du eben keine Metrik, sondern die tatsächliche Differenz. Zwei verschiedene Orte B und C können zwar zu einem Ort A den gleichen Abstand haben, aber trotzdem sind die jeweiligen Differenzen unterschiedlich.

Bezogen auf das z.B. kartesische System ist die Differenz zweier Ortsvektoren (x, y, z) wiederum ein Vektor (x, y, z). Erst wenn eine Homogenisierung des Koordinatensystems durch Einführung einer vierten Koordinate (w) erfolgt, kann anhand des Inhalts eines solchen vierdimensionalen Vektors (Ort: w=1; Richtung: w=0) eine Unterscheidung erfolgen (Das FireMonkey-Koordinatensystem wie so ziemlich alle 3D-Systeme arbeiten z.B. damit; es ist aber nur ein Trick zur Vereinfachung der Rechenoperationen für den Programmierer). Ohne diese Erweiterung ist ein 3D-Vektor ein 3D-Vektor. Ein Orts-Vektor wird nur dadurch daraus, daß man ihn auf einen definierten Nullpunkt bezieht. Da es keinen (mir) bekannten absoluten Nullpunkt gibt, ist jeder Orts-Vektor auch nur ein Differenz-Vektor zu einem willkürlich gesetzten Bezugspunkt. Es gibt also keinen Unterschied zwischen Orts-Vektoren und Differenzen zwischen ihnen.

Ebenso verhält es sich mit Zeitpunkten, die auch nur Differenzen zu einem willkürlichen Zeit-Nullpunkt sind. Vielleicht erinnert sich noch einer an die Änderung des Referenzdatums zwischen Delphi 1 und späteren Delphi Versionen. In Delphi 1 war ein TDate von 0 gleichbedeutend mit dem 31.12.1899, während in neueren Delphi-Versionen irgendein Tag um die Geburt eines galiläischen Zimmermannssohns herum als Referenz herhalten muss.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:12 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz