Strtotime() / date() Bug in PHP - all versions

I've found a biggie in PHP this week and need to report it to the
appropriate people but don't know how to, does anyone know how to report it?

Essentially the bug's in either strtotime or date. Consider the following:
$tdate = date("y_m_d", strtotime("last Sunday"));

Well this week (27 March starting), PHP reported 'last Sunday' as being
25 March 2006. 'last Sunday' is actually 26 March 2006. What makes it
even more interesting is that if I did:
$tdate = date("y_m_d", strtotime("last Sunday 10am"));

PHP correctly reports that it's the 26 March 2006.

I think it's something to do with the Daylight time saving. But
nonetheless it's still a bug because PHP should take this into account
as 'last Sunday' was definitely the 26 March 2006.

As far as I can tell, all versions are affected, I've tested it on PHP
4.3.10 (http://www.westminster-abbey.org/phpinfo.php) and 5.0.5
(http://mike-martin.com/phpinfo.php) scroll to bottom for bug demonstration.

Here's some code if anyone wants to test for themselves:

phpinfo();
print ("<h3>Date: " . date("y_m_d", strtotime("today")) . "</h3>\n");
print ("<h4>Last Sunday: " . date("y_m_d", strtotime("last Sunday")) .
"</h4>\n");
print ("<h4>Last Sunday 10AM: " . date("y_m_d", strtotime("last Sunday
10am")) . "</h4>\n");

Any thoughts / help in reporting the bug would be much appreciated.

Regards,

Mike Martin
Managing Director
gobisoft Ltd.

Message-ID: <442aba31$0$6961$ed2619ec@ptn-nntp-reader02.plus.net> from
Michael J Martin contained the following:

>I think it's something to do with the Daylight time saving. But
>nonetheless it's still a bug because PHP should take this into account
>as 'last Sunday' was definitely the 26 March 2006.

But what you are getting is the date 'last Sunday' started relative to
now.

I had a similar problem with a script I wrote for a client. It insisted
on saying that Mother's day (UK) was on a Saturday.

As you've discovered, you just have to move the point away from the
changeover time.


--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

Yeah, discovered the hard way, got an email from the clients and boss
wondering why one of our date related pages which change every Sunday
was 404-ing.

I'm still unconvinced that it's not a bug though, I think strtotime()
should take that into account and produce the appropriate timestamp
which would result in the date being the 26 March. Simply because I
wanted to know what the timestamp was for 'last Sunday' and anything
which produces a timestamp for anything that's not last Sunday is wrong
IMHO.

Message-ID: <1143660234.737193.40730@i40g2000cwc.googlegroups. com> from
Mike contained the following:

>I'm still unconvinced that it's not a bug though, I think strtotime()
>should take that into account and produce the appropriate timestamp
>which would result in the date being the 26 March. Simply because I
>wanted to know what the timestamp was for 'last Sunday' and anything
>which produces a timestamp for anything that's not last Sunday is wrong
>IMHO.

To be fair, the documentation does say that strtotime only /attempts/ to
give the correct timestamp. I suppose the problem is that daylight
saving is not universal. However, if my desktop computer knows when it
is, so I'll take your point that my server should also.

Does mktime() have the same problem?

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

| To be fair, the documentation does say that strtotime only /attempts/ to
| give the correct timestamp.

just to razz you a bit...

all software /attempts/ to do what it should. now to be more accurate than
fair/apologetic, it is far better for a function to *fail* when such
/attempts/ cannot be concluded successfully. i'd rather get an error thrown
my way or *nothing at all* returned from said function instead of *wrong* or
unexpected results.

otoh, [if digital cameras worked this way and, ] if this kind of thing
happened when i took pictures of beautiful women but the camera's /attempts/
failed to clothe them...not only would i be forgiving...i'd buy more. some
unexpected results are quite splendid indeed. ;^)

Either way, I just thought it would be appropriate to let the devs who
work on strtotime know that which is why I posted here, to try and find
out what the reporting process is.

I'm not bashing the function, it usually does a fantastic job.

Mike

robert wrote:
> | To be fair, the documentation does say that strtotime only /attempts/ to
> | give the correct timestamp.
>
> just to razz you a bit...
>
> all software /attempts/ to do what it should. now to be more accurate than
> fair/apologetic, it is far better for a function to *fail* when such
> /attempts/ cannot be concluded successfully. i'd rather get an error thrown
> my way or *nothing at all* returned from said function instead of *wrong* or
> unexpected results.
>
> otoh, [if digital cameras worked this way and, ] if this kind of thing
> happened when i took pictures of beautiful women but the camera's /attempts/
> failed to clothe them...not only would i be forgiving...i'd buy more. some
> unexpected results are quite splendid indeed. ;^)
>
>

Make sure to check the default server time. Once way to tell is look at the date and times of
uploaded files via FTP. If you upload a file a 2pm but the file say 10pm then the server time is
not syncd to your local time. That could through off some dates

On Wed, 29 Mar 2006 17:47:54 +0100, Michael J Martin <mikem@gobisoft.com> wrote:

>I've found a biggie in PHP this week and need to report it to the
>appropriate people but don't know how to, does anyone know how to report it?
>
>Essentially the bug's in either strtotime or date. Consider the following:
>$tdate = date("y_m_d", strtotime("last Sunday"));
>
>Well this week (27 March starting), PHP reported 'last Sunday' as being
>25 March 2006. 'last Sunday' is actually 26 March 2006. What makes it
>even more interesting is that if I did:
>$tdate = date("y_m_d", strtotime("last Sunday 10am"));
>
>PHP correctly reports that it's the 26 March 2006.
>
>I think it's something to do with the Daylight time saving. But
>nonetheless it's still a bug because PHP should take this into account
>as 'last Sunday' was definitely the 26 March 2006.
>
>As far as I can tell, all versions are affected, I've tested it on PHP
>4.3.10 (http://www.westminster-abbey.org/phpinfo.php) and 5.0.5
>(http://mike-martin.com/phpinfo.php) scroll to bottom for bug demonstration.
>
>Here's some code if anyone wants to test for themselves:
>
>phpinfo();
>print ("<h3>Date: " . date("y_m_d", strtotime("today")) . "</h3>\n");
>print ("<h4>Last Sunday: " . date("y_m_d", strtotime("last Sunday")) .
>"</h4>\n");
>print ("<h4>Last Sunday 10AM: " . date("y_m_d", strtotime("last Sunday
>10am")) . "</h4>\n");
>
>Any thoughts / help in reporting the bug would be much appreciated.
>
>Regards,
>
>Mike Martin
>Managing Director
>gobisoft Ltd.