ISO 8601 の時刻について考察してみた 2018-12-11 (火) 00:45:28+09:00

PHP による XML-RPC API 利用メソッドの実装に関わって、 ISO 8601 の日本版規格であるJISX0301から、時刻の表記について考えてみた。

この規格では、時刻にどのような値が取り得るのか、どのような値は不正なのか。

JISX0301 規格を読むと、夜の12時についての説明があり、

  • a)基本形式[000000]拡張形式[00:00:00]を一日の始まり
  • b)基本形式[240000]拡張形式[24:00:00]を一日の終わり
  • 一日の終わりは、次の日の始まりと同一とする

とされていた。

時刻について、25時とか26時という表記が許されるのか、また、24:00:00を超えた時刻表記、例えば、24:15:30などが許されるのかについて考えてみた:

5-3 時刻 この規格は、普通使われている24時制を基としており、時は[00]~[24]、分は[00]~[59]、秒は[00]~[60]の2けたの数字でそれぞれ表記する。一般的用途では時刻は、4けたの数字[hhmm]で表す。

[24]という時の表記は、夜の12時を表記する場合にだけ許される(5.3.2参照)。

[60]という秒の表記は、正のうるう秒又はその秒内の時点を支持する場合にだけ許される。

という説明があった。「夜の12時」とは、ジャスト12時のことだと考えられるので、24時という表記が許されるのは、一日の終わりである[24:00:00]を表記する場合のみ、と考えられる。[24:00:01]すら許されないということだ。

また、この説明中の「…秒は[00]~[60]の2けたの数字でそれぞれ表記する」を読んで、「あれ?」と思った。普通に考えると、「…秒は[00]~[59]の2けたの数字でそれぞれ表記する」となるはずでは?現に、「分は[00]~[59]の2けたの数字で表記する」とされている、秒も同じと考えるのが自然な思考だ。おそらく、説明中に出てくる「正のうるう秒」という部分がカギになっているだろうと考え検索してみたら見つかった。

国立天文台の「うるう秒」の説明によると、

  • 古くは、地球の自転を基準にして「1日」の長さが決められ、その24分の1を1時間、さらにその60分の1を1分、その60分の1を1秒としていた。
  • 原子時計で正確な時間が測定できるようになると、実は地球の回転速度にはムラがあり、常に等速で回転しているわけではないことが分かった。
  • 地球の自転が遅い状態が続いたり、速い状態が続いたりすると、地球の自転で決まる時刻と原子時計で決まる時計のずれが大きくなる。
  • そのようなとき、時刻のずれを修正するために「うるう秒」を実施する。
  • 地球の自転速度は、原子時計と比較されながら観測が続けられていて、地球の自転と原子時計によって決まる時刻の差が±0.9秒の範囲に入るように、うるう秒による調整が行われている。
  • 地球の自転と原子時計の時刻の差が1秒に達するような場合に、うるう秒として1秒を挿入することによって、時刻の調整を行う。
  • うるう秒による調整は、6月か12月の末日の最後の秒(世界時)で行われる。
  • それでも調整しきれない場合、3月か9月の末日の最後の秒(世界時)でも行われる。
  • 地球の自転が遅い(1回転にかかる時間が長い)場合には、23時59分59秒の後に23時59分60秒として1秒を挿入し、その次の秒が00時00分00秒となる。
  • 地球の自転が速い(1回転にかかる時間が短い)場合は、23時59分58秒の次の59秒をとばし、00時00分00秒にすることにより、1秒減らす。
  • ただし、日本の地方時は、世界時より9時間進んでいるため、日本では7月か1月の初日(それでも調整しきれない場合、4月か10月の初日)の午前8時59分の最後の秒で調整が行われる。

ということだそうだ。実際、1972年にうるう秒による調整が開始され、それ以来、2014年までに25回のうるう秒(いずれも挿入)が実施されているようだ。(余談だが、うるう秒については、この説明よりさらに深い説明が国立天文台に掲載されており、それを読むと、なぜ、現在までのところ、正のうるう秒だけが実施されているのかなどが分かる。(地球の自転が徐々に遅くなってきているため。)

ただし、うるう秒の実施については、うるう年のように計算で求められるものではなく、地球の自転速度の変化を長期にわたって予測ができないため、将来の実施時期は不明だそうだ。

前振りが長くなったが、うるう秒についてのバリデーションが可能かどうかについて考察すると、うるう秒がいつ挿入されるかは、UTCにおいては5月または12月または3月または9月の末日の一日の終わりの最後の秒と決まっているので、 XML-RPC での実装を考えると、サーバの規定するローカル時刻のUTCからの時差を考慮し、その時差分を差し引けば、サーバの規定するローカル時刻での、うるう秒が実施される可能性のある日時を決定することは可能だが、実際にうるう秒が実施された時刻かどうかの判定は、過去に実施されたすべてのうるう秒のデータベースでも持たない限り不可能だし、未来に関しては決定不可能だ。あくまで「うるう秒が来る可能性のある日時」しか分からない。

考えてみれば、 UNIX time はうるう秒なんぞ考慮に入れていない。未来の日時が、うるう秒の追加でいつ1秒ずれるかなんて分かるわけもないし、過去にうるう秒が追加されるたびに、 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 を利用したメソッドに対し、うるう秒の時刻が送られて来ることは考えられる。そのときのことを考慮すると、「エラーにはせず、1秒ずれた時刻として扱われる」という形にする必要があるが、 DateTime クラスの例のように、「60秒はエラー」として false を返したり例外を投げたりするクラスや関数があるだろうことを考えると、コードの全体を注意深く確認して修正しないといけないだろうし、便利に使用していた標準クラスや関数が「使えなく」なるかも知れない。うるう秒対策って、結構面倒な問題なのではなかろうか。