時間の限界値

きっと誰もが通る道だと思われる日付や時間の処理。

今回作ってるものの場合、完全にローカル依存だからそれほど複雑ではないけれど。

ローカルなんだろ？好きなもん使えや。ＦＡ。

ということだと思うのですが、スマートフォンには扱える時間の範囲が決まっています。

UNIXベースというか、UNIX時間を使うものなら何でもそうらしいのです。

2038年問題のwikipediaから抜粋。2013/08/21 06：57時点

『1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒（閏秒を考慮しない場合）を過ぎると、この値がオーバーフローし、負と扱われる[2]ため、時刻を正しく扱えていることを前提としたコードがあれば、誤作動する。』

抜粋以上。

原因としては32bitで秒の計算を行う際にオーバーフローして負の数になるのが原因とのこと。

対策も同wikiより抜粋。

『対策としては、time_t型を符号つき64ビット整数型（一般にはlong long int型）にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807（263 - 1）である。これを秒数に用いるとおよそ西暦3000億年[4]まで使用できるので、事実上問題が発生することはない。最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。』

抜粋以上。

だそうです（ぁ

ちなみにwindowsphoneだと3000年まではいけるそうです。

手持ちのスマホandroid4.0.4で時間をいじってみる。

機内モードにして、ネットワークから時刻を取得するチェックを外す。

タイムゾーンをグリニッジ標準時に手動で変更。

端末設定の日付と時刻の日付設定を変更。

2030年12月31日までは正しい日付が取れました。

2031年01月01日を設定すると設定が反映されませんでした。

うちのスマホ君はこれが限度値らしいです。

インターフェイスはDatePickerのスピナーの方でした。setMinとかsetMaxしてるってことかな。

長期なガントチャートやライフログの場合は注意が必要かと思います。

日付の取得や表示が何に依存しているのか理解した上で、

何をベースにやろうとしているのか確認することをおすすめします。

自前のUtilクラスで一本化しておくとメンテナンスも良さそうです。