2038年是很多系統都會遇到的問題(於 2038年1月19日3時14分07秒 會跳回 1970 或其他時間), 詳細可見: 2038年問題
- 註1: 32bits: 1970年1月1日 00:00:00 UTC ~ 2038年1月19日 03:14:07 UTC
- 註2: 64bits: 可記錄至2900億年後的 292,277,026,596年12月4日15:30:08 星期日(UTC)
PHP 在 2038 年的計算上, 也都做好相關的處理囉~
詳見: Is Your PHP Application Affected by the Y2K38 Bug? (下述範例取自此文)
傳統 strtotime()、date() 於 32bits 與 64bits 系統差異
<?php
$date = '2040-02-01';
$format = 'l d F Y H:i';
$mydate1 = strtotime($date);
echo date($format, $mydate1); // Wednesday 01 February 2040 00:00 就是正確結果
?>
- 32bits 結果: Thursday 01 January 1970 07:00
- 64bits 結果: Wednesday 01 February 2040 00:00
若是 64bits 的系統, 不用修改任何程式, 就可以避開 2038年 的問題囉~ 🙂
使用 DateTime 來處理日期 2038年的問題
PHP 於 5.2.0 版以後, 提供了 DateTime 的物件, 不用管 32bits / 64bits 都可以解決 2038年的問題. 🙂
<?php
$date = '2040-02-01';
$format = 'l j F Y H:i';
$mydate2 = new DateTime($date);
echo $mydate2->format($format); // Wednesday 01 February 2040 00:00 就是正確結果
?>
- 32bits 結果: Wednesday 1 February 2040 00:00
- 64bits 結果: Wednesday 1 February 2040 00:00
以後程式要多用 DateTime 來處理, 之後再來把相對應的 Function 做個對照表.
不错 支持 收获不小!
不用擔心這個問題,因為 2012 地球就毀滅啦 XD
哈哈, 那應該多及時行樂. 🙂
Thanks.看來是沒辦法用Php向C程序傳遞一個大於2038年的時間戳
可以吧, 只要 C 可以接收下來應該就沒問題了. ccc 😛