Re: strange behaviour with strtotime()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ford, Mike wrote:

Uhm -- my mistake, sorry -- 31st Feb equates to 3rd March, not 2nd, so 3rd April here is correct.

The basic thing is that strtotime() just uses the same day-of-the-month when calculating in months -- so, on the 31st January, it reckons thus:

+1 month:  31st February -- *doesn't exist* converted to 3rd March
+2 months: 31st March    -- OK
+3 months: 31st April    -- *doesn't exist* converted to 1st May
+4 months: 31st May      -- OK
+5 months: 31st June     -- *doesn't exist* converted to 1st July

etc., etc.

So you just have to be careful when calculating next/previous months to allow for strangeness like this near the end of a month -- just as you have to watch out for DST transitions if calculating with times near 01:00/02:00/03:00.  If all you're interested in is the actual month, your best bet is to normalize to a date that exists in every month (such as 1st) before doing your next/previous calculation.

Your table is quite ok.
But converting dates just because it doesnt exist and on the next added month doing so as if there was everything ok is a bug for me. 31st January -> +1 month -> 31st February (not possibele so its 3rd February) -> +1 month -> 31st February (What the O_o)

How does he calculate?
For me 3rd Fabruary -> +1 Month -> is 3rd March
also 31st January -> +2 Month -> is for me 3rd March

31st February is not true because i miss "3" (!!) days.

Not for you?

Barry


--
Smileys rule (cX.x)C --o(^_^o)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux