Description:
------------
Found existing "Won't Fix" bug report for version 4.3.9:
#30545 strototime() returns -1 on @timestamp

Would like to petition that this gets another look in 5.x.
derick@php.net asked...
"What's the point of doing this in the first place?"

I can think of a couple;
1) To support the specification as documented and published.
2) It's a time-consuming "gotcha" when you run into it, especially since the docs state different behavior.
3) in an OO API, I may not know how the date is coming in, but want to support the widest variety of possible values. 
4) One could then use strtotime() to validate a timestamp?

The third issue is the one that got me. I wrote a Date Object (that used and wrappered many of php's date functions) that I could use in an OO framework. The constructor accepts a timestamp or any valid strtotime() input as a constructor arguement.

This allows me to do something like the following to create copies/clones, without "loosing time"
$d1 = new Date();
$d2 = new Date($d1->getTimestamp());

My initial code passed the input to strtotime() and threw an Exception if there was a problem. For the current code, I wrote a workaround, but agree with the previous post that this is a legitimate bug, primarily because it diverges from stated/documented behavior.


Reproduce code:
---------------
$timestamp = time();
$strtime = strtotime('@'.$timestamp);
echo $strtime;
if($timestamp == $strtime){
   echo 'strtotime accepts a timestamp';
}

Expected result:
----------------
{a legitimate timestamp}
strtotime accepts a timestamp

Actual result:
--------------
-1 (or FALSE using 5.1.x)