1

Problem with Zend_Date and ISO_8601 format

 2 years ago
source link: https://www.codesd.com/item/problem-with-zend-date-and-iso-8601-format.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Problem with Zend_Date and ISO_8601 format

advertisements

Frankly, I'm flummoxed. Can anyone tell me why I would get a failure message with this code?

$date = Zend_Date::now();
$date = $date->getIso();

if(Zend_Date::isDate($date, Zend_Date::ISO_8601)) {
    print('success');
} else {
    print('failure');
}

exit;

It also fails if I just pass in a Zend_Date object.

UPDATE:

a var_dump of the initial $date object looks like this:

object(Zend_Date)#107 (8) { ["_locale:private"]=> string(5) "en_US" ["_fractional:private"]=> int(0) ["_precision:private"]=> int(3) ["_unixTimestamp:private"]=> int(1257508100) ["_timezone:private"]=> string(14) "America/Denver" ["_offset:private"]=> int(25200) ["_syncronised:private"]=> int(0) ["_dst:protected"]=> bool(true) }

And a var_dump of the $date string after calling $date->getIso() looks like this:

string(25) "2009-11-06T04:48:20-07:00"

I am using ZF 1.9.5 on PHP 5.2.8. I am using XAMPP for Windows too if that makes a difference.


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?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK