Bug #66980 [Nab]: Last day of Fenruary
| From: | ab@php.net | Date: | Wed, 02 Apr 2014 17:34:15 +0000 |
| Subject: | Bug #66980 [Nab]: Last day of Fenruary | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-185049@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
Updated by: ab@php.net
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:
> As I wrote in the first comment, I noticed this bug at 29th of March.
When some timestamp is passed, it's logic to have precedence. With no timestamp like this
date("j.n.Y", strtotime('last day of february'))
it takes the current year and the result is fine, too. Either it's today or on March 29th, I
don't see how it differs from an arbitrary day of year. But if you pass March 29 explicitly, it
has precedence over 'last day of february'.
Thanks
Previous Comments:
------------------------------------------------------------------------
[2014-04-02 16:46:59] tm8544 at hotmail dot com
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 }
};
------------------------------------------------------------------------
[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";
}
------------------------------------------------------------------------
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