どの時間を使うか
パソコンから日時を取得するのは簡単だ。しかし、ネットワーク上で利用するデータとなると、どのパソコンから取得した日時を使っているのかが問題になる。すでに述べたように、パソコンの内蔵時計は簡単に狂う。
ここで、ブログに記事を書きこむことを考えてみよう。
2006年(平成18年)4月24日13時20分30秒に本文が登録され、その直後にコメントが書きこまれたとしよう。コメントを書きこんだPCの時計が遅れており、コメントのタイムスタンプが2006年(平成18年)4月24日13時20分20秒になってしまったとする。第三者がこのブログを見たらどう思うだろうか。本文よりコメントの方が早く書かれているということになる。このブログの信頼性はかなり低いと解釈されても仕方ないだろう。
このような問題を避けるため、タイムスタンプの基準となる時計は1つに限定する。一般的には、サーバの時計を利用する。
ここで、ブログに記事を書きこむことを考えてみよう。
2006年(平成18年)4月24日13時20分30秒に本文が登録され、その直後にコメントが書きこまれたとしよう。コメントを書きこんだPCの時計が遅れており、コメントのタイムスタンプが2006年(平成18年)4月24日13時20分20秒になってしまったとする。第三者がこのブログを見たらどう思うだろうか。本文よりコメントの方が早く書かれているということになる。このブログの信頼性はかなり低いと解釈されても仕方ないだろう。
このような問題を避けるため、タイムスタンプの基準となる時計は1つに限定する。一般的には、サーバの時計を利用する。
時差の問題
次に問題になるのが時差である。
インターネットは世界中からアクセスできる。
先ほどのブログの例で、本文が2006年(平成18年)4月24日13時20分30秒に日本で書きこまれたとしよう。この時刻をそのままカリフォルニア州でも表示すると、アメリカ人ユーザーは違和感を感じるだろう。なぜなら、そのとき、カリフォルニアの時計は2006年(平成18年)04月23日20時20分を示しているからだ。
もちろん、カリフォルニアで未来の日本のブログが読めるわけではない。両者に17時間という時差があるためだ。
このような問題を避けるため、一般的に、以下の2つの方法がとられる。
インターネットは世界中からアクセスできる。
先ほどのブログの例で、本文が2006年(平成18年)4月24日13時20分30秒に日本で書きこまれたとしよう。この時刻をそのままカリフォルニア州でも表示すると、アメリカ人ユーザーは違和感を感じるだろう。なぜなら、そのとき、カリフォルニアの時計は2006年(平成18年)04月23日20時20分を示しているからだ。
もちろん、カリフォルニアで未来の日本のブログが読めるわけではない。両者に17時間という時差があるためだ。
このような問題を避けるため、一般的に、以下の2つの方法がとられる。
- タイムスタンプはローカル時間とし、世界標準時から何時間ズレているのか明示する。クライアント側でローカル時間に変換する。
- タイムスタンプは世界標準時とし、クライアント側でローカル時間(現地時間)に変換する。
標準形式 = RFC 3339
インターネットでは、日時をあらわす標準形式として「ISO 8601」が定められている。
ISO 8601 形式は RFC 3339 とほぼ同じ内容である。日本では、JIS X 0301 として規格化されている。
RSS のように XML で定義されたデータ形式でも、タイムスタンプとして ISO 8601 が用いられている。
ISO 8601 の表記例を下表に示す。
ISO 8601 形式は RFC 3339 とほぼ同じ内容である。日本では、JIS X 0301 として規格化されている。
RSS のように XML で定義されたデータ形式でも、タイムスタンプとして ISO 8601 が用いられている。
ISO 8601 の表記例を下表に示す。
ISO 8601 表記 | 日本語表記 |
---|---|
2006-04-12 | 西暦2006年4月12日 |
2006-04-12T23:20Z | 西暦2006年4月12日23時20分UTC |
2006-04-21T23:20:52Z | 西暦2006年4月21日23時20分52秒UTC |
2006-04-21T23:20:50.32Z | 西暦2006年4月21日23時20分50.32秒UTC |
2006-04-19T16:10:40.22-08:00 | 西暦2006年4月19日16時10分40.22秒 (米太平洋標準時間;UTCから-8時間の時差) |
2006-04-19T16:10:40.22+09:00 | 西暦2006年4月19日16時10分40.22秒 (日本標準時間;UTCから+9時間の時差) |
2006-01-01T08:59:60+09:00 | 西暦2006年1月1日8時59分60秒 (日本標準時間;閏秒を示す) |
ISO 8601 をプログラムで扱う場合、文字列として扱うのが定石だ。時刻まで表示するかどうか、秒の有効数字をどこまで記述するかなど、プログラムの都合に応じて自由に設定することができる。
一方、データベースソフトによくある date 型や time 型は、精度がデータベースに依存していたり、時差を表現することができない。
したがって、データベースに格納するデータについても、ISO 8601 を利用する方がインターネット時代に適していると言えよう。
一方、データベースソフトによくある date 型や time 型は、精度がデータベースに依存していたり、時差を表現することができない。
したがって、データベースに格納するデータについても、ISO 8601 を利用する方がインターネット時代に適していると言えよう。
e-文書法とタイムスタンプ
このように正確なタイムスタンプが登録できるようになると、その日時にそのデータファイルが作成された(更新された)というアリバイになりうる。ただし、一度付与されたタイムスタンプは、絶対に改変されないという保証をもうけてやらなければならない。
2005年(平成17年)4月1日に施行された「民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律」と「同法施行に伴う関係法律の整備等に関する法律」の2法(いわゆるe-文書法)にともない、各省庁から個別にタイムスタンプの要件が公表され、タイムスタンプがアリバイとして機能するようにした。
たとえば財務省の「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則の一部を改正する省令(H17.1.31 財務省令第一号)」によると、
タイムスタンプ技術の国際標準として最も知られているのが、PKIのデジタル署名を基にした「IETF RFC 3161(Time Stamp Protcol)」という規格で、タイムスタンプのプロトコル、およびタイムスタンプ要求・応答のデータフォーマットを定義している。このほかにも「ISO/IEC 18014」があるが、これも RFC 3161 をベースにしたものである。
2005年(平成17年)4月1日に施行された「民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律」と「同法施行に伴う関係法律の整備等に関する法律」の2法(いわゆるe-文書法)にともない、各省庁から個別にタイムスタンプの要件が公表され、タイムスタンプがアリバイとして機能するようにした。
たとえば財務省の「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則の一部を改正する省令(H17.1.31 財務省令第一号)」によると、
第三条五項ニ-ハとなっている。
当該国税関係書類をスキャナで読み取る際に、電子署名が行われている当該国税関係書類に係る電磁的記録の記録事項に財団法人日本データ通信協会が認定する業務に係るタイムスタンプを付すこと。
タイムスタンプ技術の国際標準として最も知られているのが、PKIのデジタル署名を基にした「IETF RFC 3161(Time Stamp Protcol)」という規格で、タイムスタンプのプロトコル、およびタイムスタンプ要求・応答のデータフォーマットを定義している。このほかにも「ISO/IEC 18014」があるが、これも RFC 3161 をベースにしたものである。
参考サイト
- e-文書法
- ISO 8601:ISO
- RFC 3339(和訳)
- RFC 3161(和訳):IPA
(この項おわり)
Windows や Mac OS のデータファイルにタイムスタンプがあるのはもちろんだが、データベースに格納されている1つ1つの情報にもタイムスタンプが付与されることが多い。
このように、タイムスタンプを使う場面は非常に多いのだが、意外と正確なデータ形式で登録されていないプログラムが多い。なぜか。