PHP Errechnen eines durchschnittl. Datums

[Dsimon24]

Hallo zusammen,

ich versuche gerade mittels PHP das Durchschnitt-Datum einer Gehaltszahlung
zu ermitteln. Leider komme ich aber unabhängig von PHP zu keiner Formel, die
einem so etwas ausrechnen kann. Vielleicht hat einer einen Tipp, wie ich an die
Sache rangehen könnte!?

Beispiel: Erhalte ich das Gehalt Im Januar am 26., im Februar am 28.,
erhalte ich es durchschnittlich am 27. - logisch.

Wie rechne ich das aber für folgende Gehaltseingänge aus?

02.01.2019​	2.000,00 €	für Januar 19
29.11.2018​	2.000,00 €	für Dezember 18
31.10.2018​	2.000,00 €	Für November 18
01.10.2018​	2.000,00 €	für Oktober 18
31.08.2018​	2.000,00 €	für September 18

Vielleicht hat einer ne Idee, wie das gehen könnte!?

VG, David

 

[abcddcba]

Was genau kannst du jetzt nicht? Du willst doch den Durchschnitt ueber die Tage eines Montas nehmen, oder nicht? Also nimmst du von jedem Monat einfach den Tag aus dem Datum. Was genau brauchst du jetzt noch? Ich verstehe das Problem nicht.
Ob Durchschnitt hier Sinn macht, sei mal dahingestellt - ich denke nicht. Stell dir vor, einmal am 1. des Monats, einmal am 31. des Monats. Durchschnitt waer dann 15. - das ist natuerlich nicht was du willst. Du brauchst eher sowas wie ein Tag im Monat, wo alle anderen den gleichen Abstand an Tagen haben. Bei einem Clustering waer das sowas wie das Zentrum von einem Cluster z.B.

 

[new Account()]

Setze den 1. Des Monats auf 0 und nutzen ihn als Referenzwert

 

[davisx2]

Du könntest den niedrigsten Tag der zweiten Monatshälfte (also alles ab dem 15ten im Monat) als Referenz nehmen bzw als 0. Jeder Tag danach ist eins mehr. Das führt uns zu folgenden Werten:
29ter: 0, 30ter: 1, 31ter: 2, 1ter: 3, 2ter: 4.
Dann darüber den Mittelwert. In deinem Fall also (4+0+2+3+2)/5 = 2.2.
Je nachdem wie du das bewerten möchtest, kriegst du das Geld also eher am 31ten oder am 1ten.
Hier wird davon ausgegangen, dass jeder Monat 31 Tage hat, was natürlich nicht ganz akkurat ist, aber ich hoffe für eine Denkhilfe reicht das

 

[owned139]

Haste nen DateTime Objekt oder einen Timestamp?
Lass dir einfach die Monatstage ausgeben und teile sie durch die Anzahl.
Als Beispiel:
Jan. 25, Feb. 26, März 27 wäre dann (25 + 26 +27) / 3 = 26

Beim Timestamp kommst du mittels date('j', $timestamp); an den Tag oder falls es ein DateTime Objekt ist, kannst du es mittels $date->format('y'); machen.

 

[Raijin]

Man könnte bei Tag<5 einfach Tag+30 als Berechnungsgrundlage heranziehen, um den Monatswechsel rauszurechnen. Dann bildet man den Durchschnitt und wenn dieser dann im worst case 32+ ist, rechnet man wieder zurück und kommt auf den 2.

 

[mastaqz]

Ob Durchschnitt hier Sinn macht, sei mal dahingestellt - ich denke nicht. Stell dir vor, einmal am 1. des Monats, einmal am 31. des Monats. Durchschnitt waer dann 15. - das ist natuerlich nicht was du willst. Du brauchst eher sowas wie ein Tag im Monat, wo alle anderen den gleichen Abstand an Tagen haben. Bei einem Clustering waer das sowas wie das Zentrum von einem Cluster z.B.

Ja, ohne den Sinn der Aufgabe ist das recht sinnlos.
Geht es um die automatische Bezahlung von Rechnungen,
wäre eine Orientierung am Median sehr viel sinnvoller.

Haste nen DateTime Objekt oder einen Timestamp?
Lass dir einfach die Monatstage ausgeben und teile sie durch die Anzahl.
Als Beispiel:
Jan. 25, Feb. 26, März 27 wäre dann (25 + 26 +27) / 3 = 26

Beispiel: (1 + 1 + 1) / 3 = 1

Das Unternehmen zahlt nun ein Mal einen Tag früher, am 31.:
(1 + 31 + 1) / 3 = 11
Hat sich nun das Datum um 21 Tage nach vorne geschoben?
Macht logisch wenig Sinn.

Du könntest den niedrigsten Tag der zweiten Monatshälfte (also alles ab dem 15ten im Monat) als Referenz nehmen bzw als 0. Jeder Tag danach ist eins mehr. Das führt uns zu folgenden Werten:
29ter: 0, 30ter: 1, 31ter: 2, 1ter: 3, 2ter: 4.
Dann darüber den Mittelwert. In deinem Fall also (4+0+2+3+2)/5 = 2.2.
Je nachdem wie du das bewerten möchtest, kriegst du das Geld also eher am 31ten oder am 1ten.
Hier wird davon ausgegangen, dass jeder Monat 31 Tage hat, was natürlich nicht ganz akkurat ist, aber ich hoffe für eine Denkhilfe reicht das

Ich denke, das ist bisher am sinnvollsten.

 

[owned139]

Das Unternehmen zahlt nun ein Mal einen Tag früher, am 31.:
(1 + 31 + 1) / 3 = 11
Hat sich nun das Datum um 21 Tage nach vorne geschoben?
Macht logisch wenig Sinn.

Er will den Durchschnitt wissen und der Durchschnitt berechnet sich nun mal aus der Summe aller Zahlen dividiert durch die Anzahl und ja, in deinem Fall ist der Durchschnitt richtigerweise 11.

 

[new Account()]

#EingangspostDesTEsVerstehen

 

[simpsonsfan]

Der Sinn dieser Aufgabe erschließt sich mir mit den gegebenen Informationen auch noch nicht.
Wenn der Durchschitt (also das arithmetische Mittel) aus Kalendertagen berechnet werden soll, kommt bei (1+31) logischerweise 16 raus und das entspricht dann auch der Aufgabenstellung.
Es lassen sich (sehr, sehr) viele verschiedene Wege aufbauen, um die Daten irgendwie zu mitteln. Ohne den Zweck zu kennen ist das aber alles nicht zielführend.

Falls es ein Zahlungsziel gibt, könnte man beispielsweise auch die Abweichung hierzu auswerten.
Man würde dann bspw. sagen, Zahlungsziel für einen Monat ist jeweils der erste dieses Monats im Voraus (btw. auch nicht schlecht, ich krieg mein Geld erst nach getaner Arbeit). Jetzt kann für jede Zahlung die Abweichung vom ersten (des zugehörigen Monats) in Tagen herangezogen und gemittelt werden. Die Anzahl der Tage pro Monat ist hierbei egal.

Ich kann mir noch diverse andere Verfahren vorstellen, aber wie gesagt, ohne zu wissen, was hinten rauskommenm soll, ist das eigentlich alles sinnlos.

 

[new Account()]

Wenn der Durchschitt (also das arithmetische Mittel) aus Kalendertagen berechnet werden soll, kommt bei (1+31) logischerweise 16 raus und das entspricht dann auch der Aufgabenstellung.

Es soll Der Durchschnitt Von einem Datum berechnet werden != Durchschnitt des Monatstags...

 

[simpsonsfan]

Das mag schon sein, genau definiert ist es aber nirgends.
Es steht nur da "Durchschnitt-Datum einer Gehaltszahlung" und "Erhalte ich das Gehalt Im Januar am 26., im Februar am 28., erhalte ich es durchschnittlich am 27. - logisch."
Was passieren soll, wenn das Gehalt im Januar am 31. kommt, im Februar am 28., ist unklar. Soll da 29,5 rauskommen? Ich halte es für relativ sinnlos, eine solche Angabe zu machen. Der Februar hat nichtmal 29,5 Tage.
Deswegen halte ich es auch nicht für sinnvoll, die unterschiedliche Monatslänge zu ignorieren.

 

[Raijin]

Der Sinn erschließt sich mir auch nicht, aber der Durchschnitt von 1 und 31 ist in jedem Fall sinnfrei. Man muss die Werte untereinander in Bezug bringen, normieren, bevor man rechnet. Ich würde entweder alle Werte <5 auf den 1. des Vormonats referenzieren - man bekommt dann eine Reihe von Werten zwischen 28 und 35 - oder aber man referenziert auf den letzten des (Vor)Monats und bekommt lauter +-5 Werte. So oder so wird das Ergebnis aber nur theoretischer Natur sein - nicht nur wegen unterschiedlich langer Monate, sondern auch wegen Wochenenden. Die Aussagekraft dieser Rechnung ist daher eingeschränkt.

 

[new Account()]

Was passieren soll, wenn das Gehalt im Januar am 31. kommt, im Februar am 28., ist unklar. Soll da 29,5 rauskommen?

Eigentlich ist es nicht unklar. Es kommt "letzter Tag des Monats raus".
Bezogen auf den Februar ist es halt der 28. und bezogen auf den Januar der 31.
Lösen kann man das (zumindest unter der Annahme, dass die Abweichungen kleiner 28 Tage sind) wie in #2, #3 beschrieben.
@Raijin s Lösung ist auch ein Ansatz aber mit der Limitierung auf <5 unnötig unflexibel.

 

[Raijin]

<5 war jetzt nur ein Beispiel. Man muss eine Grenze ziehen ab wann man nach oben bzw unten referenziert. Wahrscheinlich hast du aber Recht und die 5 war schlecht gewählt. <Monatsmiete wäre wohl sinnvoller.

Auch sollte man darüber nachdenken ob das arithmetische Mittel hier überhaupt das richtige Werkzeug ist. Der Median wäre robuster gegenüber Ausreißer - natürlich auch nur bezogen auf eine normierte Stichprobe. Das ist aber schwierig einzuschätzen, ohne den Sinn des Ganzen zu verstehen


*edit: Kommando zurück! Da es sich ja um Gehaltsabrechnungen handelt, sollte die Referenz natürlich der dazugehörige Monatsanfang sein, um zB auch arg verspätete Zahlungen adäquat zu erfassen. Kommt die Zahlung für den Januar erst Anfang März, muss die Referenz entsprechend der 1. Januar sein und somit ein Wert von ~60 in die Rechnung einfließen. Sonst sieht man diesen Zahlungsverzug nicht.

 

[new Account()]

<5 war jetzt nur ein Beispiel. Man muss eine Grenze ziehen ab wann man quasi auf- oder abrundet.

Muss man?
Mit deiner Lösung? Ja.
Generell?

Der Median wäre robuster gegenüber Ausreißer

Das ist aber schwierig einzuschätzen, ohne den Sinn des Ganzen zu verstehen

Ja, ohne Einsatzzweck/Kontext kann man hier keine Aussage darüber treffen. Auch nicht über die Relevanz von Wochenenden.

 

[Raijin]

Muss man?
Mit deiner Lösung? Ja.

Na klar bei meiner Lösung. Ob das gut ist? Keine Ahnung, war nur eine Idee
Wir wissen ja nicht was damit überhaupt bezweckt wird und wie hoch die Fehlerquote ist. Habe aber in #15 noch etwas editiert.

 

[simpsonsfan]

Es kommt "letzter Tag des Monats raus".

Warum soll dann bei 26.1. und 28.2. als Ergebnis 27. rauskommen und nicht zweieinhalb Tage vor Monatsende? Für mich ist es nicht klar.
Ich würde ja, wie in #10 beschrieben, die Differenz zum Zahlungszieltag hernehmen und mitteln. Aber wie wir uns mittlerweile alle einig sind:

Wir wissen ja nicht was damit überhaupt bezweckt wird

 

[owned139]

Vielleicht ist es auch einfach nur eine Programmieraufgabe aus der Schule und ihr fachsimpelt unnötig rum?

 

[new Account()]

Warum soll dann bei 26.1. und 28.2. als Ergebnis 27. rauskommen und nicht zweieinhalb Tage vor Monatsende? Für mich ist es nicht klar.

linkes Beispiel: Referenzwert ist im aktuellen Monat
rechtes Beispiel: Referenzwert ist im darauf folgendem Monat
Je nachdem stimmt daher das eine oder das andere