Bug #66980 [Nab]: Last day of Fenruary

From: Date: Wed, 02 Apr 2014 16:46:59 +0000
Subject: Bug #66980 [Nab]: Last day of Fenruary
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-185048@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=66980&edit=1 ID: 66980 User updated by: tm8544 at hotmail dot com Reported by: tm8544 at hotmail dot com Summary: Last day of Fenruary Status: Not a bug Type: Bug Package: Date/time related Operating System: Windows 7 PHP Version: 5.5.10 Block user comment: N Private report: N New Comment: In time functions, 'first' and 'next' provide the same relative but it this always right? Next and previous should produce relative values, all others are not so relative. /* The relative text table. */ static timelib_lookup_table const timelib_reltext_lookup[] = { { "first", 0, 1 }, { "next", 0, 1 }, { "second", 0, 2 }, { "third", 0, 3 }, { "fourth", 0, 4 }, { "fifth", 0, 5 }, { "sixth", 0, 6 }, { "seventh", 0, 7 }, { "eight", 0, 8 }, { "eighth", 0, 8 }, { "ninth", 0, 9 }, { "tenth", 0, 10 }, { "eleventh", 0, 11 }, { "twelfth", 0, 12 }, { "last", 0, -1 }, { "previous", 0, -1 }, { "this", 1, 0 }, { NULL, 1, 0 } }; Previous Comments: ------------------------------------------------------------------------ [2014-04-02 16:26:28] tm8544 at hotmail dot com As I already said in the first comment, there are ways to get around this problem, you just have to be aware that strtotime() behaves funny in certain conditions. But again, in my opinion "last day of february (or any month)" is not a relative date which depends on how many days any month has, or what is the current date. Last day of any month should be considered as an absolute date. For February, you naturally have to take into account whether it is a leap year or not. ------------------------------------------------------------------------ [2014-04-02 15:34:18] ab@php.net It makes more sense to use the 1st of a month, so here's your snippet modified to work correctly <?php $months = array("january", "february", "march", "april", "may", "june", "july", "august", "september", "october", "november", "december"); foreach ($months as $i => $month) { $string = "last day of " . $month; echo $month ." - " . date("j.n.Y", strtotime($string, mktime(0,0,0,($i+1),1,2014))) . "\r\n"; } ------------------------------------------------------------------------ [2014-04-02 15:28:45] ab@php.net Wait a minute, but that is correct. It just moves up to the next valid "last day of ". The same way if you try echo date("j.n.Y", mktime(0,0,0,2,29,2014)) . "\r\n"; you will get 1.3.2014 because Feb 2014 has 28 days, not 29. Btw. the behavior is consistent with Linux as well. Thanks ------------------------------------------------------------------------ [2014-04-02 15:05:56] ab@php.net Yes, now I can reproduce it with the change you mentioned, thanks. <?php $months = array("january", "february", "march", "april", "may", "june", "july", "august", "september", "october", "november", "december"); foreach ($months as $month) { $string = "last day of " . $month; echo $month ." - " . date("j.n.Y", strtotime($string, mktime(0,0,0,3,29,2014))) . "\n"; } ------------------------------------------------------------------------ [2014-04-02 12:59:02] tm8544 at hotmail dot com This bug depends on the date when you run the snippet. Optional second parameter of strtotime ( string $time [, int $now = time() ] ) plays key role in this bug. As I wrote in the first comment, I noticed this bug at 29th of March. If I run the code today, there seems to be no problem. Try these two ways to test this bug: 1) change your computer's date to 29.3.2014 and run the snippet, or 2) replace line 6 of the snippet with the following: echo $month ." - " . date("j.n.Y", strtotime($string, mktime(0,0,0,3,29,2014))); You might also be interested to test with changing line 6 to echo $month ." - " . date("j.n.Y", strtotime($string, mktime(0,0,0,3,31,2014))); Besides February, note also April, June, September and November. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=66980 -- Edit this bug report at https://bugs.php.net/bug.php?id=66980&edit=1

« previous php.bugs (#185048) next »