Hi there.
I'm running ZF 1.9.4 and PHP 5.2.10 on Ubuntu and was able to reproduce the exact same problem you had. Being the curious type, I did a little digging. Within the code for isDate, a call was made first to getDate within the companion class Zend_Locale_Format. This is wrapped around a try-catch loop, so within the catch portion, I had it dump the exception to stdout. Here's what the exception dump showed me:
exception 'Zend_Locale_Exception' with message 'Unable to parse date
'2009-11-06T04:26:46-08:00' using 'dd mm yy' (d y)' in /usr/share/php/libzend-framework-php/Zend/Locale/Format.php:995
Stack trace:
#0 /usr/share/php/libzend-framework-php/Zend/Locale/Format.php(1116): Zend_Locale_Format::_parseDate('2009-11-06T04:2...', Array)
#1 /usr/share/php/libzend-framework-php/Zend/Date.php(4583): Zend_Locale_Format::getDate('2009-11-06T04:2...', Array)
#2 {censored}/testbed/test.php(26): Zend_Date::isDate('2009-11-06T04:2...', 'c')
#3 {main}
Doing a var_dump on this exception was a little more telling about those opaque Arrays. Each of them contained the following:
array(4) {
["locale"]=>
string(5) "en_US"
["date_format"]=>
string(8) "dd mm yy"
["format_type"]=>
string(3) "iso"
["fix_date"]=>
bool(false)
}
So, date_format doesn't look right at all. It should be "YYYYMMDD'T'hh:mm:ssP," or something like that, in PHP date formatting lingo (I quoted the T, since it's the literal 'T' and not a timezone abbreviation). Granted, PHP just abbreviates it as 'c'.
Strange. So where in the world is it getting this date format? From _getLocalizedToken:
protected static function _getLocalizedToken($token, $locale)
{
switch($token) {
case self::ISO_8601 :
return "dd mm yy";
break;
...
That format looks completely wrong, given the output that ISO_8601 produces.
I would probably check with the people on the appropriate Zend list, but at first glance, this looks like something worthy of a bug report. Maybe they just don't support checks this particular type of date string yet?