2010-11-05 66 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