2010-11-05 24 views
4

可能是一个愚蠢的问题,但我需要找到答案。我们正在编写的应用程序需要处理遥远的过去和未来的日期,我认为如果我正确理解PHP manual,我们将日期处理为64位Unix时间戳将是一个简单的解决方案,它表明最大的int值是平台相关的并始终签名。因此,一个x64平台应该支持2^63个咬合,而一个x86平台应该支持2^31个最大咬合。x64 PHP/MYSQL版本会在64位Windows服务器上支持完整的64位时间戳

基本上,应用程序只处理整数时间戳,使我们相当复杂的算法稍微“简单”一点。然而,试图处理遥远的过去或将来的时间戳值会导致我们当前的x86版本中PHP的任何值大于+/- 2^31的预期溢出。我的解决方案是使用免费的Visual C++工作室下载简单地编译x64 PHP版本,但在深入研究之前,我想知道我的假设是否正确 - “Windows x64 PHP版本将正确处理64位int值,并正确地将Windows'ticks'转换为64位Unix时间戳,用于其原生日期/时间函数,就像为x86构建一样。“

例如:

echo mktime(0, 0, 0, 12, 31, 2055); 

将返回,而不是正确的时间戳。

同样的事情适用于MYSQL时间戳。例如:

SELECT UNIX_TIMESTAMP('2065-11-30 10:30:19'); 

将返回正确的值,而不是“0”因为它为我们当前运行的x86版本。

- 我希望我不太模棱两可。提前致谢。我们只是一群科学怪才,而不是真正的程序员,并且正在为这个“微不足道的”问题而努力。

回答

1

有趣的问题:我尝试了一段时间后运行一些测试,期待完整的64位时间戳给我的大爆炸和太阳之间的日期范围燃烧,但发现它仍然只有低32位在传递给date()函数时正在处理,即使回显时间戳整数值显示完整的64位范围。

EDIT

然而,设置使用的值的64位范围内的DateTime对象毫无问题的工作。

+0

那么这就是我们所处的同一条船。一个愚蠢的web应用程序,用于远程处理我们将转储到mysql中的仪器生成的快速和脏数据。我试图追踪源代码中的实际时间戳函数,看看交易是什么。尽我所能将类型定义为long,如果使用x64指令进行编译,应该使用64位,但我认为,但在网上找到的所有内容似乎都是相反的。我担心为了向后兼容而出现某种“错误”纠正。 – DrPerdix 2010-11-05 19:20:08