wo ist der september?

[FoXMorayn]

<?php
$timezone = 'Europe/Berlin';
date_default_timezone_set($timezone);

$timestamp = 1312063200;
for($i=0;$i<=20;$i++)
{
    echo date("Y m d",$timestamp);
    echo "<br>";
    $timestamp = strtotime("+1 month",$timestamp);
}
?>

ausgabe:
2011 07 31
2011 08 31
2011 10 01
2011 11 01
2011 12 01
2012 01 01
2012 02 01
2012 03 01
2012 04 01
2012 05 01
2012 06 01
2012 07 01
2012 08 01
2012 09 01
2012 10 01
2012 11 01
2012 12 01
2013 01 01
2013 02 01
2013 03 01
2013 04 01



es soll monatlich ein betrag gezahlt werden, angebrochene monate zählen als vollständig, es wird nicht anteilig gerechnet, start der zählung kann auch mitte oder ende des monats sein.
yeah, ich bekomme ich september 2011 keine rechnung!

mein gefühl sagt mir, dass das schon so seine berechtigung hat, nur wie erklär ich das dem kunden? bzw wo liegt der knackpunkt?
flach gedacht ist der 30.9. genau einen monat weiter.
in den statistiken erscheint nur der monat, es ist aber dennoch gewünscht, dass tagesgenau gerechnet wird.

 

[Anusha]

https://bugs.php.net/bug.php?id=44073

Das sollte es erklaeren ;)

 

[achtelpetit]

Alter Indianertrick, wenn Du viel mit Datum rechen muß: mach Dir eine Datumstabelle, also für jeden Tag einen Datensatz anlegen.
Das kostet nicht viel (10 Jahre = ungefähr 3.650 Datensätze) und Du kannst auch Datümer anzeigen und berechnen, die in einer "echten" Tabelle gar nicht vorkommen, also NULL sind.
Weiterhin ist so eine Datumstabelle der richtige Speicherplatz für Zeiträume, die sich prinzipiell nicht errechnen lassen: Urlaub, manche Feiertage und ähnliches.
Es kann sogar lohnend sein, diese Tabelle ausnahmsweise nicht zu normalisieren und zum Beispiel die Wochentagsbezeichnungen in einer extra Spalte mitzuführen.

 

[FoXMorayn]

https://bugs.php.net/bug.php?id=44073

Das sollte es erklaeren ;)

"Status: Bogus" was soll mir das nun sagen? ist das ein bug der anerkannt ist, oder hat der meldende einen denkfehler? steh da im moment etwas aufm schlauch.
ich werd beim 31. einfach mal 24h abziehen und mir die ergebnisse anschauen.

@achtelpetit
das muss ich mir mal durch den kopf gehen lassen. würde heißen, dass ich statistiken nicht mehr live berechne sondern im vorfeld, oder zeitversetzt per cronjob und dann über/in diese datentabelle lege?

 

[achtelpetit]

dass ich statistiken nicht mehr live berechne sondern im vorfeld, oder zeitversetzt per cronjob und dann über/in diese datentabelle lege?

nein, so ist das nicht gemeint. Du arbeitest mit Abfragen auf Deine "echten" Tabelle und die Datums-Hilfstabelle. Der Witz besteht darin, daß Du damit auch Daten anzeigen kannst, die in Deiner "echten" Tabelle nicht vorhanden sind.
Beispiel:
Du hast eine Urlaubstabelle, angegeben sind der erste und der letzte Urlaubstag. Wenn Du eine Auflistung jedes einzelnen Urlaubstags brauchst, fragst Du die Hilfstabelle nach allen Datümern von-bis, und fertig.
Es ist für diesen Fall nicht mehr nötig, sich mit einer Schleife alle Tage von-bis Stück für Stück auszurechnen.

 

[FoXMorayn]

ich denk mal nen tag drüber nach.

tag|monat|jahr|ist ein urlaubstag
[... über 10 jahre]

jetzt hab ich ein start und ein enddatum. lasse ich mir alle ergebnisse zwischen diesem datum ausgeben, kann ich mir alle betroffenen monate ausgeben lassen. 31.08 - 01.09 sollte aber eine rechnung im august erzeugen und nicht für den sepember. diese dürfte erst am 30.09 erzeugt werden. mhh.

würd mich über ein beispiel freuen.

ps:
es soll wohl ein bugfix mit mktime für '+1 month' möglich sein.

 

[achtelpetit]

würd mich über ein beispiel freuen.

Nee, rumprobieren mußt Du selber.
Viel Erfolg dabei.

 

[Anusha]

Falls du php 5.3 verwendest:

Many similar reports... and it's NOT a bug. From PHP 5.3 and higher you can do: "[...] first day of next month" or even "last day of next month" - those are always safe to use with just a "m" or another month date format specifier.

 

[FoXMorayn]

Falls du php 5.3 verwendest:

liefert auch mit php 5.3 bei "+1 month" falsche ergebnisse. da hat wohl jemand eine andere sicht von dem begriff "+1 month" ;)

 

[Anusha]

Ja bei "+1 month" ist es klar dass es nicht das erwartete Ergebniss liefert
(Waer ja auch seltsam,
wenn 28.01 , 29.01, 30.01, 31.01 "+1 month" alle den 28.02. ausspucken...


Hast du mal "last day of next month" probiert, das funktioniert prima ;)

<?php
$timestamp = mktime(0,0,0,1,29,2001);
echo date('Y.m.d',$timestamp);
$timestamp = strtotime("last day of next month",$timestamp);
echo "<br />";
echo date('Y.m.d',$timestamp);
?>

Ausgabe :

2001.01.29
2001.02.28

 

[FoXMorayn]

folgende ausgabe ist für mich "+1 month". wenn ich vom 15. einen monat weiter springe lande ich beim 15. nächsten monats und wenn ich vom 31., den letzten tag im monat, auf den letztentag des nächsten monats springe, will ich nicht auf dem 1. landen.
daher wirkt mir die aussage von der php seite ehr nicht durchdacht. sehe es auch ehr als spielerei an solche funktionen wie "last day of next month" zu integrieren, da es schon mktime und date gibt. die strings zu strtotime sind übrigens auch nicht dokumentiert und existieren eigentlich garnicht offiziell. kann daher niemandem raten sich auf diese funktionen zu verlassen. vom prinzip her finde ich die sache aber klasse, wann ließt man schon im klartext, was im code passiert?


2011 02 15
2011 02 15
2011 03 15
2011 04 15
2011 05 15
2011 06 15
2011 07 15
2011 08 15
2011 09 15

2011 01 28
2011 02 28
2011 03 28
2011 04 28
2011 05 28
2011 06 28
2011 07 28
2011 08 28
2011 09 28

2011 01 31
2011 02 28
2011 03 31
2011 04 30
2011 05 31
2011 06 30
2011 07 31
2011 08 31
2011 09 30

 

[mermshaus]

Doch, dokumentiert sind die Ausdrücke schon: PHP: Relative Formats - Manual

So richtig glücklich bin ich mit derlei „Klartext“-Ausdrücken aber – ohne das begründen zu können – auch nicht.