2桁 (あるいは3桁) の西暦年号への、各仕様などの解釈方法の説明について。 RFC 2626 は、それ以前に発行された RFC の仕様に存在する2000年問題を検証しています。 *判断する時点の日付を元に判断 **RFC 2068, RFC 2616 (HTTP/1.1) 19.3 曰く: > HTTP/1.1 clients and caches should assume that an RFC-850 > date which appears to be more than 50 years in the future > is in fact in the past (this helps solve the "year 2000" problem). HTTP/1.1 クライアントとキャッシュは、50年以上未来の RFC 850 日付を、実際は過去のものと解釈するべきです (これが「2000年」問題解決の 手助けとなります)。 *29-30を境界とする **Microsoft Windows 00〜29 → +2000, 30〜99 → +1900 Windoze 98 以降では、[[コントロールパネル]]の「地域」で変更出来ます。 *49-50 を境界とする **RFC 2822 RFC 2822 4.3 曰く: > Where a two or three digit year occurs in a date, the year is to be > interpreted as follows: If a two digit year is encountered whose > value is between 00 and 49, the year is interpreted by adding 2000, > ending up with a value between 2000 and 2049. If a two digit year is > encountered with a value between 50 and 99, or any three digit year > is encountered, the year is interpreted by adding 1900. 日付内で2桁や3桁の年が出てきたら、年は次のように解釈します。 2桁年号が00〜49の値の場合、2000を加えて2000〜2049の値と解釈します。 2桁年号が50〜99の値の場合、または3桁の年号の場合は、 1900を加えて解釈します。 **JIS X 0603:2000 [[JISX0603]]:2000 『情報交換用フレキシブルディスクカートリッジのラベル及びファイル構成』 8.5.15, 8.5.20 では、2桁年号で00〜49に+2000, 50〜99に+1900して 解釈します。ただし、2050年以降は使ってはいけません。 *68-69を境界とする **X/Open の推奨 00〜68 → +2000, 69〜99 → +1900 を推奨しているらしいです。 *38-39を境界とする 38年を境に、39年以降が1900年代にする実装が少なからずあります。 (一部の [[M$]] 製品を含みます。) 根拠はよく分かりません。 ([[Un*x時間]]の32ビット限界の関係?) *See also - - -[[日付形式]] -[[RFC822と仲間達の頭領域名]] *ライセンス See [[RFCのライセンス]]