57

タイムスタンプを使用して物を注文する Web アプリがありますが、これは単に長いだけです。私の Web アプリのバックエンドはたまたま Java で記述されているため、以下を使用しています。

long timestamp = System.currentTimeMillis();

これは（およそ）何年に失敗しますか？つまり、ある時点で long の範囲がオーバーフローするということですよね? 私たちは皆、とっくに死んでいるかもしれませんが、私はただ興味があります. それは再びy2kのようになりますか？これに備えるにはどうすればよいですか？ばかげている、私は知っている、ただ好奇心が強い！

4

6 に答える 6

129

でオーバーフローします

System.out.println(new Date(Long.MAX_VALUE));

印刷する

Sun Aug 17 03:12:55 GMT-04:00 292278994

したがって、それは 2 億 9,200 万年を少し超えた後のことです。それまでの間、解決策を考え出す時間は十分にあると思います。正直なところ、人類がこれを生き残るとは思っていません。私たちは時間スケールで世界の年齢に比べて数秒しか存在しておらず、長くはかかりません.

ここに画像の説明を入力

于 2010-06-04T23:49:04.223 に答える
14

このコードを実行してみてください:

System.out.println(new Date(Long.MAX_VALUE));

ロケールに応じて、次のようなものが出力されます。

Sun Aug 17 17:12:55 EST 292278994

将来は非常に長いので、オーバーフローを心配する必要はありません。

于 2010-06-04T23:50:28.837 に答える
11

8 月 17 日 (日) 17:12:55 EST 292278994 (他の人の計算による) に Web アプリがまだ存在する可能性は低いようです。その場合、あなたがまだ Web アプリを担当する可能性はさらに低いと思われます。（あなたがまだ責任を負っている場合、将来的にはおそらくより高いレートで支払われることになるので、今はスライドさせて、後で大金を回収してください:)

システムクロックが異常な値に誤って設定されている可能性が非常に高いです。これは比較的簡単に準備できます - 以下の擬似コード

long reasonableDate ( )
{
     long timestamp = System.currentTimeMillis();
     assert timestamp after 2010AD : "We developed this web app in 2010.  Maybe the clock is off." ;
     assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD.  Maybe the clock is off." ;
     return ( timestamp ) ;
}

これらのアサーションのいずれかがトリガーされたときに生きている場合は、システム クロックの修正またはアサーションの変更 (必要に応じて) のいずれかに対して、おそらくクライアントに大金を請求できます。

于 2010-06-05T01:15:41.700 に答える
10

「これに備えるにはどうすればいいですか？」

まあ、棺桶に最新かつ最高のIT機器/オタクのおもちゃを装備することができます. しかし、どういうわけか、西暦292,278,994年には少し「時代遅れ」になると思います. そして、あなたはそれまでに彼らにかなり退屈するでしょう.

128 ビット クロックを使用するように OS をゼロから書き直す時間は十分にあります。時間を無駄にする楽しいプロジェクトのように思えます。:-)

于 2010-06-04T23:57:07.043 に答える
6

Java の最大値は でlongあり2^63 - 1、そのミリ秒数を実際の時間単位に変換すると、約 2 億 9000 万年でカウンターがオーバーフローすることがわかります。だから心配しないでください ;-) 誰かがまだコンピュータを動かしているなら、それまでに 128 ビットの時間カウンタに切り替えている (または新しいエポックを選んでいる) と確信しています。

于 2010-06-04T23:49:35.410 に答える