w3cdtf

W3C-DTF

[1] 俗に W3C-DTF と呼ばれる日付形式は、 W3C会員企業である Reuters LimitedW3C提出した ISO 8601の日付形式プロファイルです。

[8] 「W3C-DTF」と呼ばれている日時形式は、実際には W3C が制定したものではありません (>>33)。

[3] ISO 8601 は、様々な応用を考慮して、 割と自由な日付時刻の表現形式を規定しています。 このプロファイルでは、それを Web で使うにあたって無駄な自由度をなくしており、機械処理が比較的 (あくまで比較的、元の ISO 8601 と比べれば。) 容易になっています。

[4] 必要な精度 (まで、までなど) で6種類の書式が定義されています。

本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。

(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)

目次

  1. 代替
  2. 仕様書
  3. 暦法
  4. 構文
  5. 閏秒
  6. 解釈
  7. 文脈
  8. Date construct (Atom 0.3)
    1. 内容
    2. 関連
  9. SMIL の日付形式
  10. timestamp (Amazon Ion)
  11. 関連
  12. 歴史
  13. メモ

代替#

[27] 既に W3C-DTF を用いることと決められている場合を除き、 日時W3C-DTF によって表現するべきではありません。

[31] W3C-DTF仕様書は、手続き上は廃止されていません (W3C Note なので「現行」も「廃止」も無いのかも?)。 しかし、現代の基準では標準規格として十分な品質を有しておらず、 十数年間誰にもメンテナンスされず放置されており、 XML SchemaHTML5 をはじめとした新しい世代の仕様からも参照されていません。 従って、実質的には失効しているとみなすべきでしょう。

[28] HTML その他 Web 上では、一般に HTMLの日時形式のいずれかを用いるのが便利と思われます。 HTMLの日時形式

[29] XML では、 xs:dateTime を用いるのが良さそうです。 W3C-DTF に関する W3Cスタッフコメントからも、それが当時の W3C の意向であることがうかがえます (>>10)。

仕様書#

[33] W3CWebサイトで公開されていますが、 W3C 会員企業が W3C提出したことを表すだけであり、 W3C の正式な規格ではありません。 当時の W3C の制度では W3C Note となっていますが、 現在の制度下であれば Member Submission と呼んで区別されているものです。 W3C Note

[70] W3C-DTF のように W3C NoteW3C規格と誤認された事案の反省から Member Submission 制度が創設されたと思われますが、 過去に遡って整理していないため誤解が現在までずっと続いているのです。

暦法#

[30] 明示されていませんが、 ISO 8601のプロファイルであることから ISO 8601 の規定に従い先発グレゴリオ暦を採用しています。

[71] 構文上の制約から、表現可能な範囲はそこから更に狭まっています。

[72] 日本の元号タイの仏暦中華民国の民国紀元には対応していません。

[74] イスラム暦東アジアの旧暦には対応していません。

構文#

[40] 利用する場面によって粒度が異なるとして幾つかの構文が定義されており、 どれを採用するか利用するプロトコルの側で選択することになっています >>5

[41] 次の6種類の構文が示されています >>5

[48] ここで、各要素は次のような値です >>5

[50] 各要素の詳細な意味については、 ISO 8601 に委ねているためか、 特に記述がありません。 ISO 8601 が採用する仕様の側に決定を委ねているグレゴリオ改暦以前のの解釈などは、 W3C-DTF でどう処理するべきかはっきりしません。 0000 も禁止 (も許可も) されていません。

[49] TZ大文字小文字について明記されていませんが、 特に規定がないことから大文字でなければならないと解釈するのが一般的です。

[73] RFC 3339の日時形式のように小文字を認める ISO 8601のプロファイルもあるので注意。

閏秒#

[18] この日付形式閏秒に対応していません。

解釈#

[51] W3C-DTF であると期待される文字列をどう解釈するべきかについては、 まったく規定がありません。

[52] 例えば 2015-02-31 のような存在しない日付を与えられた時、 どう解釈するべきかは不明です。

文脈#

[12] 古い HTML 仕様である HTML4引用規格としてこの仕様を参照していますが、 それを引いている %Datetime; 型の定義ではまでの書式と同じものが (参照ではなく) 陽に定義されています。 当時の規定の詳細は %Datetime; を、現在の規定は HTMLの日時形式を参照

[13] DCMI メタデータで定義されている語 date は、この仕様のまでの書式を推奨しています。 語 W3CDTF はこの仕様の書式を表すとされています。 (が、どの書式なのか、あるいは全部なのかは、よくわかりません。)

[24] RSS 1.0 でよく用いられる dc:date 要素の値は W3C-DTF とされています >>25。 どの形式なのか、すべてなのかは明記されていませんが、一般的には、また仕様暑中の例示では、 時間帯まで含まれた形式が使われています。

[57] その他 RDF語彙が採用していることがあります。

[61] RKMSの日時形式W3C-DTF でした。

Date construct (Atom 0.3)#

[15] かつて用いられていた Atom 0.3 では、 Date construct >>22内容が「W3C Date-Time string」である要素とされていました。

内容#

[16] 要素によっては、時間帯が示されているべき、 示されるなら UTC でなければならないといった制約が更に課されています。

関連#

[17] Atom 0.3 の改訂版に当たる Atom 1.0Date constructRFC 3339の日付形式XML Schemaの日付形式を採用しています。 XML Schemaの日付形式

SMIL の日付形式#

[19] SMIL はいくつかの日時時間の表現方法を定義しています >>20 が、 日時日付時刻に関しては、 W3C-DTF基づいている (based upon) とされています。 W3C-DTF で定義されている書式の1つである日付 + 時刻 (秒の小数部まで表現可能) + 時間帯の完全形のほかにも、 日付時刻時間帯を省略した書式も定義されています。

[26] W3C-DTFInformative References の1つとして挙げられているに過ぎず、 それに「基づいた」構文を SMIL 側で独自に規定しています。

[21] 閏秒に対応していないのも同じです。

timestamp (Amazon Ion)#

[62] Specification, , https://amzn.github.io/ion-docs/docs/spec.html#timestamp

[63] 基本はW3C-DTF秒の小数部の桁数は [1, ∞)。 時差Z, 時差時分のどちらも可で -00:00 (unknown local offset) も使用可能。

[65] 年のみ、年月のみ、年月日のみは UTCunknown local offset と解される。

[66] UTC + unknown local offset とは -00:00 と同じ解釈のことらしい。 (unknown local offset という意味付きとはいえ、 年月日がUTC と解釈されるのは使いにくそうだが...)

[64] 年のみ、年月のみのとき直後に T が必須。 年月日の時直後に T を付けても良い (なくても良い)。

[67] 等価性 (equivalent): 同じ瞬間、精度、時差なら等しい。

[68] Ion Binary Encoding, , https://amzn.github.io/ion-docs/docs/binary.html#6-timestamp

[69] バイナリー形式はテキスト形式と違ってバイナリーデータ。 UTC での日時部品 (年から秒の小数部まで、年のみ必須) + 時差の分数で表す。 (W3C-DTF と違って日時部品は UTC の値なので、 テキストとバイナリーの変換時に書き換えが生じる。 その結果値域が微妙に違う。 -00:00 も表現できない。)

関連#

[9] ISO 8601 との関係: この仕様で規定されている書式は、 ISO 8601:1988 に基づくプロファイルです。しかし、 ISO 8601:2003 から見ると古い書式になっています。

[10] XML Schema との関係: XML Schema では、 dateTimegYear などこの仕様で規定されている書式に相当するデータ型が定義されています。

この仕様についての W3C スタッフの注釈 (XML Schema 勧告後のもの) によれば、 この仕様は既に参照している他の仕様があるのでそのまま残してあるそうですが、 今後は XML Schemaデータ型を参照するべきなのでしょう。

[11] RFC 3339 との関係: までの書式は、 RFC 3339の日付形式とほぼ同じです。

[34] EDTFW3C-DTF とも互換性があると主張しています。

[56] ODRFW3C-DTF を基にしていると謳っています。 ただし ODRF が使っているのは W3C-DTF の一部だけです。

#

歴史#

[39] draft-newman-datetime を参考にした >>5 とされています。 draft-newman-datetime は後の RFC 3339 です。

[58] かつては http://www.w3.org/TR/1998/NOTE-datetime でもアクセスできたようですが、現在では 404 です。

メモ#

[6] W3C-DTF は人間が読む文章でも使うべきものだと誤解してる連中が少なからずいると見える。 ISO 8691 も W3C-DTF も RFC 3339 も、機械処理用の記述形式でしかないのに。 (確かに W3C-DTF Note にはそんなこと一言も書いてない。自明だから書かなかったのかな。)

人間が読むための形式は言語や地域や主義主張や個人の趣味で色々で、それを統一しようとするのは愚かなこと。 W3C がそんなことするわけないじゃん。 (名無しさん 2004-09-04 02:52:38 +00:00)

[7] というかよく読めば単なる Member Submission で、 W3C が規定したわけでもなんでもないのに、誰が W3C-DTF なんて言い出したのでしょうね?

ちなみに W3C スタッフのコメントは Comment on Date and Time Formats Submission http://www.w3.org/Submission/1997/14/Comment

最近になって W3C は WG からの公式な W3C 文書と Member/Team Submission を区別するようになりましたけど、時既に遅すぎといいますか、なんと申し上げますか。 (名無しさん)

[14] >>6 W3C-DTFは人間にも読みやすくていいとか主張している人がいますけど、明らかに不自然なTが入る書式のどこがよいのでしょうかねぇ。

[23] OpenID Authentication 1.1 ( ( 版)) http://openid.net/specs/openid-authentication-1_1.html#anchor33

[32] ( 版) http://iss.ndl.go.jp/rss/ndlopac/index.xml

dcterms:issued xsi:type="dcterms:W3CDTF"2016</dcterms:issued>

Web技術

[35] Echo【bitFlyer】 () https://bitflyer.jp/ja/corporate/echo/api

リクエスト時のパラメータや、レスポンスデータ内において、日時を表現するために ISO 8601(W3C-DTF)形式(※2)の文字列を用います。タイムゾーンは JST で固定。フォーマットは“yyyy-mm-dd hh:mm:ss”。

[38] W3C-DTF には >>35 のような時間帯の指定を省略した形式は定義されていないのですが...

[36] Top-level Element: <originInfo> (MODS Ver. 3 User Guidelines: Metadata Object Description Schema, Library of Congress) () https://www.loc.gov/standards/mods/userguide/origininfo.html

Use of the encoding attribute is recommended. If an exact year is known, the DLF/Aquifer guidelines recommend representing the value using the W3CDTF encoding, which also allows month and day to be specified if known. The W3CDTF encoding is a profile of the more flexible ISO 8601 standard. Using W3CDTF ensures a more predictable format for dates. The DLF/Aquifer guidelines recommend using ISO 8601 encoding only when a date cannot be expressed using W3CDTF.

[37] Top-level Elements and Attributes (MODS Ver. 3 User Guidelines: Metadata Object Description Schema, Library of Congress) () https://www.loc.gov/standards/mods/userguide/generalapp.html

w3cdtf – This value identifies dates following the W3C profile of ISO 8601, Date and Time Formats, that specifies the extended format for dates using the pattern: YYYY-MM-DD. If hours, minutes, and seconds are also needed the following pattern is used: YYYY-MM-DDThh:mm:ss.

[53] XLIFF Version 2.0 () http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html#ctr_datetime

Value description: Date in one of the formats defined in [NOTE-datetime].

ctr:revision author="system" datetime="2013-05-15T10:00:00+8:00"

[54] >>53 の例示の日時W3C-DTF のいずれとも違う気がしますが... XML Schema の定義がありますが、なぜか xs:dateTime は使っていません。

[55] SVF PDF Archiver Web APIリファレンス () https://manual.wingarc-support.com/manual/svf/spa93apiref/?pageId=p55980886

ISO8601 RFC3339 W3CDTF(日付と時刻をTでつなげる)に準拠した文字列(例 "2016-11-22T11:18:43.933+0900")で出力します。

[60] DCMI: DCMI Metadata Terms, , https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http%3A%2F%2Fpurl.org%2Fdc%2Fterms%2FW3CDTF