Strange Date Issue, Please Help!

wshost

echo "next month: " . date("F", strtotime(date("Y-m-d", strtotime("January 31 2006")) . " +1 month"));

This outputs March but since it is January 31, it should echo February. It worked fine for the past several months until now. Any ideas? I'm stumped on this one. Seems to act the same with PHP 4.3.9 and PHP 5.0.4.

There is probably a better way to write this and that may be my problem. Any help would be greatly appreciated, thanks!

frost110


echo "next month: " . date("F", time()+60*60*24*30);

Try something like that. You can always make the 30 dynamic but that should be sufficient for what you want to do. If not create an array of all months and their days go off that.

Kind of like this:


if (date('F', time()) == "January") {
	$days = "28";
}else {
	$days = "30";
}
 echo "next month: " . date("F", time()+60*60*24*$days);

--FrosT

Installer

Or calculate from the 15th of the current month, adding one month:

echo "next month: " . date('F', strtotime('+1 month', date('m15Y')));

wshost

Installer wrote:
Or calculate from the 15th of the current month, adding one month:
echo "next month: " . date('F', strtotime('+1 month', date('m15Y')));

I had to implement this method in one area. Working from the 15th of a month is sort of a safe way to do it, but hardly seems the right way. It seems as though +1 month in PHP is being used as +31 day which obviously is not right. I had to use the following:

date("M", mktime(0,0,0,date("n")+1,1,date("Y")));

Someone else recommended I use this:

date("F", strtotime("+1 month", strtotime("January 31 2006")));

which is probably better than what I had, at least more simple, but it still returns the wrong month.

Does this seem like a PHP bug to you guys? Any potential issues you see with using the mktime() function instead?

frost110

I do not see any issues with it. The 15day thing would work out great if you ask me, better than my solution. I dunno if it is considered a bug or not. But yea, I am out of ideas, best of luck.

--FrosT

Installer

If working from the 15th is "sort of a safe way to do it" and it gives you the correct answer, then...well, I know what I'd do.

samudasu

I agree with Installer and Frost110. What's wrong with the 15th method? It works, it gives the correct result every time. What's does it need to be the "right way"?

Weedpacket

It's because "January 31 2006" plus one month is "February 31 2006" - or March 3. Same as "October 31 2005" plus one month was "November 31 2005".

Don't forget that strtotime works over the entire date and time, not just the bit you happen to want to display later. "+1 month" really does mean "Plus one month." In other words, the year isn't changed, the time isn't changed, and the date isn't changed. It's not until afterwards, when the timestamp is being reformatted back into a human-readable string, that it slips into March. (Timestamps just count seconds after all, and don't care about what month it is.)

Counting from the 15th would work, but then so would counting from the 1st and look less arbitrary. (This, incidentally, is what the mktime() code is doing; using mktime() here is a sight more efficient than using strtotime() which has to run a full-blown parser over the string to make sense of it and break it back down into the very same pieces you built it out of in the first place. It could be made a bit more efficient still by dropping the date('Y') argument - PHP will fill that in with the current year by default if it's not supplied.)

Installer

$start = microtime(true);
for ($n = 0; $n < 100000; $n++) {
    $next_month = date('F', strtotime('+1 month', date('m09Y')));
}
echo microtime(true) - $start . '<br />';

$start = microtime(true);
for ($n = 0; $n < 100000; $n++) {
    $next_month = date('F', strtotime('+1 month', date('m01')));
}
echo microtime(true) - $start . '<br />';

$start = microtime(true);
for ($n = 0; $n < 100000; $n++) {
    $next_month = date('M', mktime(0, 0, 0, date('n') + 1, 1)); 
}
echo microtime(true) - $start . '<br />';

1.4580359458923
1.365168094635
1.9365389347076

Be careful of dst when working from the 1st using mktime and strtotime. Maybe by setting the hour to 12 or whatever strikes you as less arbitrary.

Weedpacket

Those numbers don't really match what I'm getting with that code:
58.808119297027588
59.081838130950928
57.786509990692139
Are you counting minutes?

Installer

No, those are seconds, the exact output from that exact code. And that's how long it takes for the script to run. I wonder why the big difference? I wouldn't think it would be from mine being cached by the Zend engine and yours not (and I'm guessing that if mine was, yours would be too), as the current time should be read (twice) on each loop.

Edit: I mean "...for the Zend engine...".

Weedpacket

Funny, I suspended everything else and still got results like
34.475818872451782
34.187061071395874
33.701538801193237

I'm not running a cache (which would affect results nonlinearly, and I don't know about optimisations, but if they include preparsing arguments to date and strtotime then that would make a difference (though since they're nondeterminisitic you can't evaluate them ahead of time)), but I suspect the difference in our environments is much bigger than that.

Installer

I've tested it now on three Windows (2 v5, 1v4) and three Linux (1 v5, 2 v4) servers (all basic AMP), and get consistent results, even using a microtime conversion function on v4 (exact code as posted otherwise), with the Linux installations taking 5-10% longer, but none longer than 2.1 seconds over 100000 iterations.