PHP strptime 格式错误?
我正在解决 php 5.2.6 问题。 我们使用的 API 以 DDMMYYYYHHMM 格式返回日期。 正是这种格式,固定长度,没有分隔符。 然而,在我的实验中,这种格式似乎破坏了 strptime,当我以这种格式向它提供日期时,它会返回 false(失败)。 它可以重现,至少在我的系统上,用这个例子:
$format = "%d%m%Y%H%M"; echo print_r(strptime(strftime($format,1225405967),$format),true);
如果我在日期和时间之间添加任何字符,它就可以工作,甚至是空格。 所以,这确实有效:
$format = "%d%m%Y %H%M"; echo print_r(strptime(strftime($format,1225405967),$format),true);
我是否遗漏了一些明显的东西?
编辑:除此之外,由于评论指出的结果,这似乎是特定于平台的。 我可以在办公室运行 OSX Leopard 的 Mac 上重现它,但 Linux 机器可以很好地解析它。 我认为这是 OSX *nix 中底层 C 库中 strptime 的错误或特性。
I am wrestling with a php 5.2.6 problem. An api we use returns dates in this format DDMMYYYYHHMM. Exactly that format, fixed length, no delimiters. However, in my experimentation, this format seems to break strptime, which returns a false (fail) when I feed it a date in this format. It can reproduced, at least on my system, with this example:
$format = "%d%m%Y%H%M"; echo print_r(strptime(strftime($format,1225405967),$format),true);
If I add any character between the date and the time, it works, even a space. So, this DOES work:
$format = "%d%m%Y %H%M"; echo print_r(strptime(strftime($format,1225405967),$format),true);
Am I missing something obvious?
edit: further to this and owing to the results indicated by the comments, this seems to be platform specific. I can reproduce it on the Macs running OSX Leopard in the office but the Linux boxes parse it fine. I assume it is a bug or idiosyncrasy of the strptime in the underlying C library in the *nix of OSX.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
此函数与区域设置相关。 您是否尝试过设置不同的区域设置? (参见
setlocale()
)This function is locale-dependent. Have you tried setting different locale? (see
setlocale()
)如果您认为问题出在 MacOS X 和 C 库中,那么您可以生成一个测试用例来演示它。 例如,我在 MacOS X 10.4.11(PPC,G4,32 位)上运行下面的代码,并得到输出:
我使用的代码是:
根据我所看到的,strptime 中没有错误( )在我正在使用的版本中。 我们可以争论不存在的错误检查以及打印中的强制转换与 C99
符号的优点,但我认为代码足够准确。 我使用gmtime()
而不是localtime()
; 我怀疑这是否是无法重现问题的一个因素。也许您应该看看 PHP 测试套件?
也许您应该将相当复杂的表达式分成几部分来检测 PHP 中发生错误的位置?
If you think the problem is on MacOS X and in the C library, then you could produce a test case to demonstrate it. For example, I ran the code below on MacOS X 10.4.11 (PPC, G4, 32-bit), and got the output:
The code I used is:
On the basis of what I see, there is no bug in strptime() in the version I'm using. We can debate about the merits of the non-existent error checking, and of the casts versus C99
<inttypes.h>
notations in the printing, but I think the code is accurate enough. I usedgmtime()
instead oflocaltime()
; I doubt if that was a factor in not reproducing the problem.Maybe you should look at the PHP test suite?
Maybe you should split your rather complex expression into pieces to detect where the error occurs in PHP?
没有什么明显的,因为两个版本都可以在 PHP 5.2.0 中正常工作。 不过,我现在还不能轻易检查 5.2.6。 那得等我回家了。
Nothing obvious since both versions work fine in PHP 5.2.0. I can't readily check 5.2.6 at the moment, though. That will have to wait until I get home.
这很可能仅适用于 Mac,因为这甚至还没有在 Windows 上实现(尽管我已经通过了该建议)。
我会继续在 bugs.php.net 提交错误。
It's very likely that this is isolated to Macs only, as this hasn't even been implemented on Windows yet (although I've passed that suggestion along).
I would go ahead and submit a bug at bugs.php.net.
我确认:
输出:
数组(9){
[“tm_sec”] =>
整数(0)
[“tm_min”] =>
整数(0)
[“tm_hour”] =>
整数(0)
[“tm_mday”] =>
整数(9)
[“tm_mon”] =>
整数(1)
[“tm_year”] =>
整数(102)
[“tm_wday”] =>
整数(0)
[“tm_yday”] =>
整数(0)
[“未解析”]=>
字符串(0)“”
OS
X Leopard、PHP 5.3.2
I confirm:
Output:
array(9) {
["tm_sec"]=>
int(0)
["tm_min"]=>
int(0)
["tm_hour"]=>
int(0)
["tm_mday"]=>
int(9)
["tm_mon"]=>
int(1)
["tm_year"]=>
int(102)
["tm_wday"]=>
int(0)
["tm_yday"]=>
int(0)
["unparsed"]=>
string(0) ""
}
OS X Leopard, PHP 5.3.2