Unix時間の変換

桁から単位を判断します。10桁は秒、13桁はミリ秒。どう読んだかも表示します。

桁を取り違えると53年ずれます

Unix時間でいちばん多い間違いは、秒とミリ秒の取り違えです。 同じ数字でも、どちらとして読むかで結果がまったく変わります。

1700000000 という10桁の数を秒として読むと2023年11月14日ですが、 ミリ秒として読むと1970年1月20日になります。53年のずれです。 逆に13桁の 1700000000000 を秒として読むと、 西暦5万年より先という現実には無い日付になります。

この計算機は桁数から単位を推定し、どう読んだかを画面に書きます。 推定が違っていれば、単位のボタンで直せます。 黙って秒として読んで1970年と表示するだけでは、間違いに気づけません。

なぜ1970年が基準なのか

Unix時間は1970年1月1日0時0分0秒（UTC）からの経過秒数です。 この基準の時刻をエポックと呼びます。

1970年が選ばれた理由は、Unixというオペレーティングシステムが作られた時期に近く、 切りのよい年だったからだと言われています。 深い意味のある年ではなく、どこかに基準を置く必要があったので置いた、という性質のものです。

基準がUTCで統一されていることには意味があります。 世界のどこで記録しても同じ数字になるので、 時差の違う場所の出来事を並べて比べられます。 時差を考えるのは、人が読む形に直すときだけで済みます。

2038年に起きること

Unix時間を32ビットの符号つき整数で持っているシステムには、期限があります。 32ビットで表せる最大の値は 2147483647 で、 これが2038年1月19日3時14分7秒（UTC）にあたります。

この時刻を1秒でも過ぎると、値があふれてマイナスに転じ、 1901年12月13日として扱われてしまいます。 2000年問題と似た構造ですが、こちらは桁数ではなく整数の上限が原因です。

いまの多くのシステムは64ビットで持っているので、この問題は起きません。 64ビットなら約3000億年先まで表せます。 古い機器や、32ビットのまま動き続けている組み込み機器では、 まだ確認が必要な場合があります。