Tages-Differenz Ganzzahl ?

[MarKiesCo]

Hi,

hat jemand eine Idee, warum bei Berechnung der Anzahl der Tage, gesehen zum Jahresstart, zwischen dem (einschl.) 1.April und dem (einschl.) 27.Oktober keine Ganzzahl ist? Wird mit der Sommerzeit zusammenhängen, aber dennoch müsste es eine Ganzzahl sein, oder?

Grundsätzlich egal, aber wenn man (wie ich zuvor) bei den Berechnung nicht die ".ToFloat()" nutzt, passt das Ergebnis zur var "VarDef" eben nicht, und dann alle Folgeberechnungen in scripten nicht.

Ergebnis:
1704063600
1711839600
90.00

Code: Alles auswählen

real Start =("2024-01-01 00:00:00").ToTime().ToInteger();
real Akt =("2024-03-31 00:00:00").ToTime().ToInteger();

string VarDef = (((Akt - Start) / 3600).ToFloat() / 24).ToString(2);

WriteLine(Start);
WriteLine(Akt);
WriteLine(VarDef);

Ergebnis:
1704063600
1711922400
90.96

Code: Alles auswählen

real Start =("2024-01-01 00:00:00").ToTime().ToInteger();
real Akt =("2024-04-01 00:00:00").ToTime().ToInteger();

string VarDef = (((Akt - Start) / 3600).ToFloat() / 24).ToString(2);

WriteLine(Start);
WriteLine(Akt);
WriteLine(VarDef);

Ergebnis:
1704063600
1729980000
299.96

Code: Alles auswählen

real Start =("2024-01-01 00:00:00").ToTime().ToInteger();
real Akt =("2024-10-27 00:00:00").ToTime().ToInteger();

string VarDef = (((Akt - Start) / 3600).ToFloat() / 24).ToString(2);

WriteLine(Start);
WriteLine(Akt);
WriteLine(VarDef);

Ergebnis:
1704063600
1730070000
301.00

Code: Alles auswählen

real Start =("2024-01-01 00:00:00").ToTime().ToInteger();
real Akt =("2024-10-28 00:00:00").ToTime().ToInteger();

string VarDef = (((Akt - Start) / 3600).ToFloat() / 24).ToString(2);

WriteLine(Start);
WriteLine(Akt);
WriteLine(VarDef);

Gruß, MarKiesCo

[Henke]

Wird mit der Sommerzeit zusammenhängen, aber dennoch müsste es eine Ganzzahl sein, oder?

Nope, da weder 23/24 noch 25/24 eine "Ganzzahl" ist.

[HM-Villa]

Das "falsche" Ergebnis liegt tatsächlich an der Sommerzeit. Alle Angaben im Format "Zeit" beziehen sich auf den 01.01.1970 00:00:00. Damit enthalten Zeitdifferenzen auch immer die Uhrzeit. Der Trick ist nun, einfach mit "time.IsDST()" zu ermitteln, ob die angegebene Zeit in der Sommerzeit liegt und die fehlende Stunde bei der einen oder anderen Zeit zu addieren. Es sei auch auf Teil 1 der HM-Script-Dokumentation verwiesen. Als Denkansatz das folgende Script.

Code: Alles auswählen

time Start = @2024-01-01 00:00:00@;
Start = Start + (Start.IsDST() * 3600);
time Akt = @2024-04-01 00:00:00@;
Akt = Akt + (Akt.IsDST() * 3600);

time diff = Akt - Start;

real VarDef = ((diff.ToFloat()) / 3600) / 24;

WriteLine(VarDef);

Ich habe VarDef extra mal als real definiert, damit Du die Nachkommastellen siehst.

[Xel66]

Man könnte auch mit den Tageszahlen arbeiten (siehe Scriptdoku) und deren Differenz ermitteln (das sind per se Integerzahlen). Solange beide Tage innerhalb eines Jahres liegen, funktioniert das. Das spart man sich die ganze Sekundenrechnerei.

Gruß Xel66

[HM-Villa]

Ja schon, den Ansatz hatte ich vorher auch. Ich vermute jedoch, dass auch Zeiträume über den Jahreswechsel berechnet werden sollen. Auch wenn das ggf. am Anfang nicht der Fall sein sollte, funktioniert später dann die Berechnung nicht mehr und man muss sich wieder Gedanken machen. Mein Ansatz ist daher, den Definitionsbereich der Eingangswerte möglichst nicht einzuschränken, was hier ja auch mit wenig Aufwand möglich ist.

[Xel66]

Ich vermute jedoch, dass auch Zeiträume über den Jahreswechsel berechnet werden sollen.

Da die Ausgangsdaten ja bekannt sind, kann man bei einem negativem Ergebnis oder der Prüfung auf Differenz der Jahreszahl eine entprechende Korrektur vornehmen. Aber vielleicht ist ein .ToInteger() oder/und .Round() nach der Subtraktion der Ausgangsdaten einfacher und deckt alle Anwendungen ab.

Gruß Xel66

[HM-Villa]

Wie war das doch gleich:

Das spart man sich die ganze Sekundenrechnerei.

und

... kann man bei einem negativem Ergebnis ...
... vielleicht ist ein .ToInteger() oder/und .Round() nach der Subtraktion der Ausgangsdaten einfacher ...

Ja geht auch. Aber warum pfuschen, wenn es auf einfache Weise auch korrekt geht? Was hast Du gegen "IsDST()"?

Grüße von Uwe

[MarKiesCo]

Ja schon, den Ansatz hatte ich vorher auch. Ich vermute jedoch, dass auch Zeiträume über den Jahreswechsel berechnet werden sollen...

korrekt

[Xel66]

Was hast Du gegen "IsDST()"?

Nix dagegen. Korrektrurechnungen finde ich nur umständlicher als simples Runden oder in eine Ganzzahl zu wandeln. Jedes Rechnungsergebnis in einem überschaubaren Zeitraum wird sich in der Nähe einer Ganzzahl befinden und simples Runden oder integer-Wandeln das gleiche Ergebnis bringen. Man kann es "Pfusch" nennen, weil es mathematisch nicht ganz korrekt berechnet ist. Sind die Ergebnisse aber gleich, könnte ich auch mit dieser Lösung leben.

Gruß Xel66

[MarKiesCo]

...simples Runden oder in eine Ganzzahl zu wandeln...
Gruß Xel66

...was ich so in meinem Script tatsächlich auch getan habe

cheers