PHP による XML-RPC API 利用メソッドの実装に関わって、 ISO 8601 の日本版規格であるJISX0301から、時刻の表記について考えてみた。
この規格では、時刻にどのような値が取り得るのか、どのような値は不正なのか。
JISX0301 規格を読むと、夜の１２時についての説明があり、
- a)基本形式[000000]拡張形式[00:00:00]を一日の始まり
- b)基本形式[240000]拡張形式[24:00:00]を一日の終わり
- 一日の終わりは、次の日の始まりと同一とする
とされていた。
時刻について、２５時とか２６時という表記が許されるのか、また、24:00:00を超えた時刻表記、例えば、24:15:30などが許されるのかについて考えてみた：
５－３ 時刻 この規格は、普通使われている２４時制を基としており、時は[00]～[24]、分は[00]～[59]、秒は[00]～[60]の２けたの数字でそれぞれ表記する。一般的用途では時刻は、４けたの数字[hhmm]で表す。
[24]という時の表記は、夜の１２時を表記する場合にだけ許される（５．３．２参照）。
[60]という秒の表記は、正のうるう秒又はその秒内の時点を支持する場合にだけ許される。
という説明があった。「夜の１２時」とは、ジャスト１２時のことだと考えられるので、２４時という表記が許されるのは、一日の終わりである[24:00:00]を表記する場合のみ、と考えられる。[24:00:01]すら許されないということだ。
また、この説明中の「…秒は[00]～[60]の２けたの数字でそれぞれ表記する」を読んで、「あれ？」と思った。普通に考えると、「…秒は[00]～[59]の２けたの数字でそれぞれ表記する」となるはずでは？現に、「分は[00]～[59]の２けたの数字で表記する」とされている、秒も同じと考えるのが自然な思考だ。おそらく、説明中に出てくる「正のうるう秒」という部分がカギになっているだろうと考え検索してみたら見つかった。
国立天文台の「うるう秒」の説明によると、
- 古くは、地球の自転を基準にして「１日」の長さが決められ、その２４分の１を１時間、さらにその６０分の１を１分、その６０分の１を１秒としていた。
- 原子時計で正確な時間が測定できるようになると、実は地球の回転速度にはムラがあり、常に等速で回転しているわけではないことが分かった。
- 地球の自転が遅い状態が続いたり、速い状態が続いたりすると、地球の自転で決まる時刻と原子時計で決まる時計のずれが大きくなる。
- そのようなとき、時刻のずれを修正するために「うるう秒」を実施する。
- 地球の自転速度は、原子時計と比較されながら観測が続けられていて、地球の自転と原子時計によって決まる時刻の差が±０．９秒の範囲に入るように、うるう秒による調整が行われている。
- 地球の自転と原子時計の時刻の差が１秒に達するような場合に、うるう秒として１秒を挿入することによって、時刻の調整を行う。
- うるう秒による調整は、６月か１２月の末日の最後の秒（世界時）で行われる。
- それでも調整しきれない場合、３月か９月の末日の最後の秒（世界時）でも行われる。
- 地球の自転が遅い（１回転にかかる時間が長い）場合には、２３時５９分５９秒の後に２３時５９分６０秒として１秒を挿入し、その次の秒が００時００分００秒となる。
- 地球の自転が速い（１回転にかかる時間が短い）場合は、２３時５９分５８秒の次の５９秒をとばし、００時００分００秒にすることにより、１秒減らす。
- ただし、日本の地方時は、世界時より９時間進んでいるため、日本では７月か１月の初日（それでも調整しきれない場合、４月か１０月の初日）の午前８時５９分の最後の秒で調整が行われる。
ということだそうだ。実際、１９７２年にうるう秒による調整が開始され、それ以来、２０１４年までに２５回のうるう秒（いずれも挿入）が実施されているようだ。（余談だが、うるう秒については、この説明よりさらに深い説明が国立天文台に掲載されており、それを読むと、なぜ、現在までのところ、正のうるう秒だけが実施されているのかなどが分かる。（地球の自転が徐々に遅くなってきているため。）
ただし、うるう秒の実施については、うるう年のように計算で求められるものではなく、地球の自転速度の変化を長期にわたって予測ができないため、将来の実施時期は不明だそうだ。
前振りが長くなったが、うるう秒についてのバリデーションが可能かどうかについて考察すると、うるう秒がいつ挿入されるかは、UTCにおいては５月または１２月または３月または９月の末日の一日の終わりの最後の秒と決まっているので、 XML-RPC での実装を考えると、サーバの規定するローカル時刻のUTCからの時差を考慮し、その時差分を差し引けば、サーバの規定するローカル時刻での、うるう秒が実施される可能性のある日時を決定することは可能だが、実際にうるう秒が実施された時刻かどうかの判定は、過去に実施されたすべてのうるう秒のデータベースでも持たない限り不可能だし、未来に関しては決定不可能だ。あくまで「うるう秒が来る可能性のある日時」しか分からない。
考えてみれば、 UNIX time はうるう秒なんぞ考慮に入れていない。未来の日時が、うるう秒の追加でいつ１秒ずれるかなんて分かるわけもないし、過去にうるう秒が追加されるたびに、 UNIX time の値と経過時刻との関係をずらす処理をOSどころか全アプリケーション、既存の全日時データをアップデートして更新する、なんて馬鹿げたことをするわけもない。
そもそも PHP の日付・時刻に関する標準関数に、うるう秒を表記した日時を渡した場合どうなるかについて調べてみた：
function validateDate($date, $format = 'Y-m-d H:i:s')
{
$d = DateTime::createFromFormat($format, $date);
return $d && $d->format($format) == $date;
}
$v = '2018-12-08 23:59:60';
print 'validateDate('.$v.')='.(validateDate($v)?'true':'false').'<br />';
は、 false となった。「 DateTime クラスの createFromFormat() に渡す ‘s’ は[00]～[59] 」と、 php.net のマニュアルにも明記されている。うるう秒なぞ秒として認めない、ということだ。一方で、与えられたパラメータを元に UNIX time を返す mktime() は、引数 second に 60 以上の値を渡してもエラーにはせず、 59 より多い秒数分時刻を加算する動作をする。 「 60 秒」をエラーにするかしないかは関数によってまちまちだが、「うるう秒を考慮したものではない」ということは共通している。
要するに、うるう秒についての ISO 8601 の規定は、規定通りに処理することが現実的に無理なのだ。だが、それでも稀に XML-RPC を利用したメソッドに対し、うるう秒の時刻が送られて来ることは考えられる。そのときのことを考慮すると、「エラーにはせず、１秒ずれた時刻として扱われる」という形にする必要があるが、 DateTime クラスの例のように、「60秒はエラー」として false を返したり例外を投げたりするクラスや関数があるだろうことを考えると、コードの全体を注意深く確認して修正しないといけないだろうし、便利に使用していた標準クラスや関数が「使えなく」なるかも知れない。うるう秒対策って、結構面倒な問題なのではなかろうか。
