時刻トラブルはなぜ起こる、「日付が過去に戻る」「未来からデータが届く」の訳

　近年の企業システムの安定稼働に「時刻」の管理は欠かせない。古くは2000年直前にIT業界で大きな騒ぎになった「2000年問題」から、近年よく目にする時刻のずれに起因する認証トラブルまで、時刻にまつわるトラブルは数えられないほどたくさんある。

　まずは、時刻にまつわる典型的なトラブルをいくつか紹介する。そして、NTP（Network Time Protocol）をはじめ現在のIT機器でよく使われる時刻同期の方法を見ていこう。

古くて新しい桁あふれ問題

　IT系のエンジニアであれば、「2000年問題」という言葉を一度は聞いたことがあるだろう。2000年問題は典型的な桁あふれ問題である。1990年代以前につくられたソフトウエアやシステムでは、コンピューターの記憶領域を少しでも節約するために、年号を格納する領域を数値2桁しか確保しておらず、1990年を「90」、1999年を「99」のように保持していたシステムも多かった。こうしたシステムが2桁で2000年を表現すると「00」となるが、これでは1900年と区別がつかない。実際、2000年を1999年より過去の日付として扱い、誤動作したシステムが各所で見つかった。ほかにも、1999年の翌年を設定するために99に1を加算した「100」という3桁の数字を設定しようとして、0から99の数値以外を想定していなかったシステムが誤動作したという例もあった。

年号を格納する領域が2桁しかなかったために発生した「2000年問題」

（出所：高橋 基信）

[画像のクリックで拡大表示]

　桁あふれ問題は近年でも発生している。2021年には、バス会社でICカード乗車券の最終利用日が約20年前の日付になるトラブルが発生した。このICカード乗車券のシステムでは、人工衛星を使ったGPS（Global Positioning System、全地球測位システム）の週番号を利用して日付を計算していた。週番号は10ビット（0～1023）で管理し、毎週1ずつ加算され、1023に到達した翌週は0となる。ICカード乗車券のシステムは桁あふれを想定していなかったため、0となった週番号を過去の日付として扱ったことがトラブルの直接原因である。

　少し先の話になるが、「2038年問題」という問題もある。LinuxなどのUNIX系OSでは、従来「UNIX時間」という仕組みを使ってきた。具体的には、1970年1月1日午前0時0分0秒を0として、経過秒数を32ビットの符号付き数値（最大21億4748万3647）で管理している。このため、2038年1月19日午前3時14分7秒までしか管理できない。UNIX時間が考案された当時は2038年は遠い未来だったが、あと15年となり、そろそろ現実の問題として考えていく必要があるだろう。