Industrieminuten

[StepByStep]

Guten Morgen zusammen,

bevor die Frage aufkommen sollte: Ja, ich habe die SuFu genutzt.

Mein Problem ist folgendes:
Ich möchte zwei TDateTimes vergleichen und mir die Differenz in Stunden ausgeben lassen.
Mir sind die Funktionen YearBetween, HoursBetween, etc. bekannt und leider auch zu ungenau.
Deshalb habe ich eine eigene Funktion geschrieben:

Delphi-Quellcode:

function TXmlfunction.GetDate(dtVon, dtBis: TDateTime): string;
var
  dtDate: TDateTime;
  sHour:  string;
  sTime:  string;
begin
  dtDate := (dtBis - dtVon);
  sHour  := TimeToStr(dtDate);
  sTime  := FloatToStr(StrToFloat(sHour[1] + sHour[2]) + StrToFloat(sHour[4] + sHour[5]) / 60);
  result := sTime;
end;

Das Problem was sich nun stellt ist, dass wenn ich beispielsweise folgende Rechnung habe:

22.01.2015 10:00:00 - 21.01.2015 10:00:00,

dann ist das Ergebnis 0, da er durch den Befehl

Delphi-Quellcode:

TimeToStr()

nur die Stunden nimmt.
Ich kann aber nicht

Delphi-Quellcode:

DateTimeToStr()

nutzen, weil ich so nur Müll rausbekomme.

Frage: Wie stelle ich das jetzt am geschicktesten an?

Gruß
Jan

[DeddyH]

Wozu dieses ganze String-Geraffel, wäre z.B. DecodeDateTime nicht zielführender?

[himitsu]

Oder HourOf, MinuteOf, MinutesBetween usw.


Abgesehn von den fehleranfälligen Stringbehandlungen ... StrToFloat, obwohl man nur ganze Zahlen rein gibt.

Zitat:

Das Problem was sich nun stellt ist, dass wenn ich beispielsweise folgende Rechnung habe:

Du rechnest nur mit dem Stundenanteil, da muß es bei Tagesüberschreitungen natürlich knallen.
Wie wäre es, wenn du auch die Tages/Monats/Jahres-Anteile mit einrechnest? :roll:

Und was ist mit den MinutenSekunden-Anteilen?
22.01.2015 10:00:00 - 22.01.2015 09:30:00

Nur das Markierte wird von dir beachtet und der Rest einfach ignoriert, da kann das doch nicht richtig funktionieren.

[DeddyH]

Nach kurzer Überlegung: die Differenz zweier TDateTime ist doch in Tagen, um also auf die Stunden zu kommen, müsste man sie doch lediglich mit 24 multiplizieren, oder mache ich da einen Denkfehler?

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1287382)

Nach kurzer Überlegung: die Differenz zweier TDateTime ist doch in Tagen, um also auf die Stunden zu kommen, müsste man sie doch lediglich mit 24 multiplizieren, oder mache ich da einen Denkfehler?

Ja und Nein - kein Denkfehler :thumb:

UPDATE Aber bitte keine MagicValues im Code benutzen sondern System.SysUtils.HoursPerDay ;)

UPDATE 2 Die einzige Zahl, die keine MagicValue ist, ist die 42 :mrgreen:

[Sherlock]

Zitat:

Zitat von DeddyH (Beitrag 1287382)

Nach kurzer Überlegung: die Differenz zweier TDateTime ist doch in Tagen, um also auf die Stunden zu kommen, müsste man sie doch lediglich mit 24 multiplizieren, oder mache ich da einen Denkfehler?

Nö

Sherlock

[StepByStep]

Danke schonmal für die Antworten. Mein Programm erfasst Arbeitszeiten.

Zitat:

Und was ist mit den Minuten-Anteilen?
22.01.2015 10:00:00 - 22.01.2015 09:30:00

Mit der Funktion die ich dort geschrieben habe, werden in der Tat auch die Minuten mitgerechnet @himitsu

Zitat:

UPDATE Aber bitte keine MagicValues im Code benutzen sondern

Was genau ist eine MagicValue? Noch nie gehört.

Zitat:

Nach kurzer Überlegung: die Differenz zweier TDateTime ist doch in Tagen, um also auf die Stunden zu kommen, müsste man sie doch lediglich mit 24 multiplizieren, oder mache ich da einen Denkfehler?

Denkfehler nicht nein, aber bei mir glaube ich schon. Würde dieser Denkansatz dann aus meinem Code folgendes machen:

Delphi-Quellcode:

function TXmlfunction.GetDate(dtVon, dtBis: TDateTime): string;
var
  dtDate: TDateTime;
begin
  dtDate := ((dtBis - dtVon)*24);
  result := DateTimeToStr(dtDate);
end;

Gruß
Jan

[himitsu]

Zitat:

Zitat von StepByStep (Beitrag 1287389)

Mit der Funktion die ich dort geschrieben habe, werden in der Tat auch die Minuten mitgerechnet @himitsu

Ohhhh, da hat mir die gut benannte Variable "sHour" einen Streich gespielt. :oops:
(hab da schnell und heimlich da oben meine Antwort angepasst)

Zitat:

MagicValue

Eine einfach so im Code stehende Zahl, deren Bedeutung man nicht sofort erkennt.
Darum gibt es auch diese "sprechenden" Konstanten. (Oder man schreibt ständig "unnötige" Kommentare in seinen Code :stupid:)

DateTimeToStr wird nur zum "Konvertieren" von DateTime-Werten benutzt (Tage = ganzzahliger Anteil und Nachkommateil ist Stunden/Minuten/Sekunden ... bzw. "Tage" seit Anfang)
Mal "24" (die Fernsehserie) ist das natürlich kein DateTime-Wert mehr, sondern ein Stunden-Wert. (FloatToStr, Format, gerundet und dann IntToStr usw.)

[DeddyH]

So ungefähr, aber die 24 ist nun der angesprochene Magic Value: da steht eine 24 und niemand weiß, was sie zu bedeuten hat. Aus diesem Grund benutzt man Konstanten mit sprechenden Bezeichnern.

Delphi-Quellcode:

dtDate := ((dtBis - dtVon)*DateUtils.HoursPerDay);

So wird einem auch nach Jahren sofort klar, dass das mit Stunden je Tag zu tun hat.

[StepByStep]

Zitat:

Mal "24" (die Fernsehserie) ist das natürlich kein DateTime-Wert mehr, sondern ein Stunden-Wert.

@himitsu Was ist das für eine Fernsehsendung? Ich bin Baujahr '95 :wink: Und die Ausgabe soll auch in Stunden erfasst werden, nicht in Minuten. Wobei, naja quasi Stunden, ich hätte gerne Industrieminuten, also eine Stunde = 1, eine halbe Stunde = 0,5

Check, ich probier es gleich mal aus. :)

Gruß
Jan

Edit: DateUtils.HoursPerDay sind bei mir zwei undeklarierte Bezeichner. Ich habe in den Uses System.DateUtils eingebunden. Bin ich dumm oder sehe ich den Fehler nicht?