Zend_Date 和 ISO_8601 格式的问题

发布于 2024-08-10 10:59:45 字数 846 浏览 6 评论 0原文

坦白说,我很困惑。谁能告诉我为什么我会收到此代码的失败消息?

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

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

exit;

如果我只传入 Zend_Date 对象,它也会失败。

更新:

初始 $date 对象的 var_dump 如下所示:

object(Zend_Date)#107 (8) { ["_locale:private"]=>字符串(5) "en_US" ["_fractional:private"]==> int(0) ["_ precision:private"]=> int(3) ["_unixTimestamp:private"]=> int(1257508100) ["_timezone:private"]=> string(14) "美国/丹佛" ["_offset:private"]=> int(25200) ["_syncronized:private"]=> int(0) ["_dst:受保护"]=> bool(true) }

调用 $date->getIso() 后 $date 字符串的 var_dump 如下所示:

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

我正在使用 ZF PHP 5.2.8 上的 1.9.5。我也在使用 Windows 版 XAMPP,如果这有什么区别的话。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

与之呼应 2024-08-17 10:59:45

我在 Ubuntu 上运行 ZF 1.9.4 和 PHP 5.2.10,并且能够重现与您遇到的完全相同的问题。作为好奇的人,我做了一些挖掘。在 isDate 的代码中,首先调用伴随类 Zend_Locale_Format 中的 getDate。这是围绕一个 try-catch 循环,因此在 catch 部分中,我将异常转储到标准输出。以下是异常转储向我展示的内容:

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}

对此异常执行 var_dump 可以更清楚地了解那些不透明的数组。它们每个都包含以下内容:

 array(4) {                                                                       
          ["locale"]=>                                                                   
          string(5) "en_US"                                                              
          ["date_format"]=>                                                              
          string(8) "dd mm yy"                                                           
          ["format_type"]=>                                                              
          string(3) "iso"                                                                
          ["fix_date"]=>                                                                 
          bool(false)                                                                    
        }           

因此,date_format 看起来根本不正确。它应该是“YYYYMMDD'T'hh:mm:ssP”,或者类似的 PHP 日期格式术语(我引用了 T,因为它是文字“T”而不是时区缩写)。当然,PHP 只是将其缩写为“c”。

奇怪的。那么这个日期格式是从哪里得到的呢?来自 _getLocalizedToken:

 protected static function _getLocalizedToken($token, $locale)
    {
        switch($token) {
            case self::ISO_8601 :
                return "dd mm yy";
                break;
...

鉴于 ISO_8601 生成的输出,该格式看起来完全错误。

我可能会与相应 Zend 列表上的人员核实,但乍一看,这看起来像是值得报告错误的东西。也许他们只是还不支持检查这种特定类型的日期字符串?

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?

暮年 2024-08-17 10:59:45

抱歉,在你发布这篇文章后我读了这么久。对你来说出错的代码对我有用,尝试在 php 源中独立使用 Zend/Date 类,如下所示:


set_include_path('./lib' . PATH_SEPARATOR . get_include_path());
include_once 'Zend/Date.php';
...

而且你可能还需要像这样设置 php.ini:

include_path = ".:/usr/share/ php:/usr/share/php/smarty/libs:/opt/zend/library"

或者你的 zend 库所在的位置。

然后显示“成功”。希望有帮助。

编辑:您可能还想禁用普通的 Zend 使用,我只想要 Date 类,因为它有点令人震惊。

编辑:我使用 Zend 扩展 220060519,它似乎是 Zend Engine v2.2.0./ PHP 5.2.6-1+lenny8 当我在谷歌上搜索时,我遇到了一些链接,解释了其中有(是?)另一个 Date 类部分zend框架不一样。但我可能是错的,这个链接帮助我找到了原因,但我对当时的思维过程记忆力很差:)

Sorry I read this so long after you posted this. The code that goes wrong for you works for me, try to use the Zend/Date class standalone in the php source like this:


set_include_path('./lib' . PATH_SEPARATOR . get_include_path());
include_once 'Zend/Date.php';
...

And you probably also need to set php.ini like this:

include_path = ".:/usr/share/php:/usr/share/php/smarty/libs:/opt/zend/library"

Or where your zend libs are.

Then it shows 'success'. Hope that helps.

Edit: You probably also want to DISABLE plain Zend use, I only wanted the Date class as it kinda rocks afaik.

Edit: I use Zend extension 220060519 which seems to be Zend Engine v2.2.0./ PHP 5.2.6-1+lenny8 When I was googling this I came accross a few links that explained there is(was?) another Date class section in the zend framework which weren't the same. But I could be wrong, this link helped me finding the cause though but I have short memory concerning my thought process at the time :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文