Kalenderwochen Funktion Falsch?

[Amateurprofi]

Zitat von Daniel G:

Zitat von Amateurprofi:

Nein, das bringt nichts.

Und im selben Posting machst du es dann doch. ;)

Daniel,
lies doch mal etwas genauer, wie ich das Round(...) ersetzt habe.
Ich habe nicht einfach (wie von dir vorgeschlagen) das "Round" durch "Trunc" ersetzt sondern durch Trunc(0.5 + ...).
Du schlugst vor, mit Trunc den Nachkommateil abzuschneiden.
Ich runde ab, wenn der Nachkommaanteil < 0.5 ist und auf, wenn er >= 0.5 ist.
Round würde dann, wenn der Nachkommaanteil = 0.5 ist, auf die nächstgelegene gerade Zahl runden.
Bei dieser Routine wird dieser Fall nicht eintreten, weil bei einer Division eines Integerwertes durch 7 der Nachkommateil nie 0.5 sein kann.
Ich halte es aber für "sauberer", hier nicht Round zu verwenden, damit klar ist was gerechnet werden soll.

[Mithrandir]

Zitat von Amateurprofi:

Du schlugst vor, mit Trunc den Nachkommateil abzuschneiden.

Ja, denn der wird ja nicht gebraucht. Oder? Ich bräucht einen Beweis, welche der beiden Varianten nun richtig ist. Den find ich aber nicht. Bislang bringen beide bei mir dasselbe Ergebnis.

[mkinzler]

Wenn nur dern Datumbereich beachtet werden soll muss man abschneiden als Trunc()

[Mithrandir]

Büdde was?

[mkinzler]

Die Berechnung ist falsch, wenn der TDateTime eine Zeitangabe enthält. Deshalb muss man diese abschneiden

[x000x]

Moin moin,

Zitat von Daniel G:

...Ich bräucht einen Beweis, welche der beiden Varianten nun richtig ist...

Ich versuche es mal...

Vom übergebenen Datum interessiert ja nur der Datumteil, also die Stellen vor dem Komma.
Ob ich nun z.B. 40184 durch y teile oder 40184.xxxxx durch y, die Vorkommastellen vom Ergebnis bleiben gleich.
Und da bei ((A +8 -Day) - EncodeDate(Y, 1, 1)) / 7 nur unser übergebenes Datum Nachkommastellen haben könnte,
können wir auch bei dem Ergebnis den Nachkommaanteil ignorieren.

Also reicht es, das Round durch Trunc zu ersetzen, wie du schon im Beitrag #8 geschrieben hast.

[Mithrandir]

Zitat von x000x:

Also reicht es, das Round durch Trunc zu ersetzen, wie du schon im Beitrag #8 geschrieben hast.

Danke. Denn ich kann immer noch nicht nachvollziehen, warum es nun wichtig sein soll, 0.5 dazuzuaddieren.

[mkinzler]

Zitat:

Danke. Smile Denn ich kann immer noch nicht nachvollziehen, warum es nun wichtig sein soll, 0.5 dazuzuaddieren. Grübelnd...

Wäre sogar falsch, denn dann wäre aber Mittag der nächste Tag.

[Amateurprofi]

Zitat von Daniel G:

Zitat von Amateurprofi:

Du schlugst vor, mit Trunc den Nachkommateil abzuschneiden.

Ja, denn der wird ja nicht gebraucht. Oder? Ich bräucht einen Beweis, welche der beiden Varianten nun richtig ist. Den find ich aber nicht. Bislang bringen beide bei mir dasselbe Ergebnis.

Bei mir nicht.
Beispiele:
01.01.2010 : 52 (Richtig : 53)
02.01.2010 : 52 (Richtig : 53)
03.01.2010 : 52 (Richtig : 53)
Alle Tage des Jahres 2009.

Im Zeitraum 15.10.1582 bis 31.12.2499 bringt ein einfaches Trunc(...) an 144918 (von 335006) Tagen ein falsches Ergebnis. (Zumindest wenn ich bei all dem, was ich gemacht habe nicht völlig gepennt habe)
Der Fehler tritt bei mir auf:
1) An allen Tagen eines Jahres, wenn der 01.01. ein Dienstag, Mittwoch oder Donnerstag ist. (144269 Mal)
2) Am 01.01. und 02.01. eines Jahres, wenn der 01.01. ein Samstag ist und in die 53. Woche des Vorjahres fällt. (60 Mal)
3) Am 01.01., 02.01. und 03.01. eines Jahres, wenn der 01.01. ein Freitag ist. (396 Mal)
4) Am 30.12. und 31.12. eines Jahres, wenn der 30.12. ein Montag ist. (60 Mal)
5) Am 31.12. eines Jahres, wenn er ein Montag ist. (133 Mal)

[Mithrandir]

Ok, dann nehm ich zurück, was ich gesagt hab. Meine Testfälle waren einfach nicht richtig konstruiert. Wenn es keine größeren Proteste gibt, werde ich das morgen im Laufe des Tages in die Funktion in der CL einarbeiten.