また嘘偽りあり得ない
#ねつ造は余計じゃないか? という指摘があったので削除しました
自分で書いていることが破綻していることに気づいていないんだろうか．
本当にこの人あの本書いた人なのかなぁ…
PHPで time 関数などによってUNIXタイムを使っている人も多いはずです。
この関数では、「1171206000」のように10桁の「1970年1月1日 00:00:00 GMT」からの秒数を返します。
この10桁では、2038年以降の日付を表すことは出来ません。9999999999の次は0となってしまい、また1970年1月1日となってしまいます。
符号付き32ビット整数の上限が9999999999なわけねーだろ．2147483647だっつーの．
それを超えると浮動小数点になるので+1して0に戻る訳ねーだろ．
それ位書く前にチェックしろ．5秒あればチェックできるだろ．
$ php -r 'var_dump(0x7FFFFFFF);' int(2147483647) $ php -r 'var_dump(2147483647);' int(2147483647) $ php -r 'var_dump(2147483648);' float(2147483648) $ php -r 'var_dump(9999999999);' float(9999999999) $ php -r 'var_dump(9999999999+1);' float(1.0E+10)
この話をdate()あたりにかけてみる．
既に値は2038年問題なにそれなあっちの方向へ．
$ php -r 'var_dump(date("r", 9999999999));'
string(31) "Sun, 07 Sep 2014 13:50:07 +0900"
$ php -r 'var_dump(date("r", 9999999999+1));'
string(31) "Sun, 07 Sep 2014 13:50:08 +0900"
$ php -r 'var_dump(date("r", 2147483647));'
string(31) "Tue, 19 Jan 2038 12:14:07 +0900"PHPバージョン5.1.2移行(多分)でタイムゾーン無視してdate()で調べたいならdate.timezoneをGMTとかそれっぽいのにしてみましょう．
$ php -ddate.timezone=GMT -r 'var_dump(date("r", 2147483647));'
string(31) "Tue, 19 Jan 2038 03:14:07 +0000"これGMTな上限．+1したらあっちの方向に．
$ php -ddate.timezone=jpn -r 'var_dump(date("r", 2147483648));'
string(31) "Sat, 14 Dec 1901 05:45:52 +0900"これを見て分かるように，2147483647が上限なわけで，9999999999は上限を何回超えればいいんでしょうね．
id:blackhaltさんよりこっそり修正することあるからキャプチャした方がいいよって勧められたのでしてみるテスト．
っていうかphpspot見てる人はこのはてダみないだろうから修正しなくていいと思うYO!!
あとどうでも良いけど
そこで、Pear::Dateの使い方が紹介されてます。
はPEAR::Dateだろとか，2038年問題は孫どころか案件によっては(特に技術者なら)何年も前から既に気をつけないとこっそり現実味がある問題だことに気づいていないという．
家買っても35年ローンとか組まない人なんだろうなぁ．
って子孫はアシアルの人か．みんな若いからなぁ(笑 とか思ったけど
既に2038年を超えるデータを扱うシステムでは上記の問題に直面しているはずで す。
とかちゃんと書いてるよね．さすがアシアル．
しかし
関連エントリ
