2桁西暦年号の解釈

2桁西暦年号の解釈

[4] 西暦が2桁または3桁の数字列で表されている場合、 これをどう解釈するかが問題となります (2000年問題)。 各種のプロトコルプログラムは色々な方針を採っています。

[14] は過ぎましたが、2桁でが表わされる場面は残っており、 今後も無くなることはありませんから、これをどう解釈するか、何らかの判断は必要です。

判断する時点の日付を元に判断

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年」問題解決の 手助けとなります)。

[6] RFC 7231 もこれを踏襲しています。

Time::Local

[10] Perlモジュール Time::Local は現在から前後50年以内と解釈します >>9

29-30を境界とする

Microsoft Windows

00〜29 → +2000, 30〜99 → +1900

Windoze 98 以降では、コントロールパネルの「地域」で変更出来ます。 <http://www.microsoft.com/japan/year2k/2kwhitepaper/settings_jp.htm>

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を加えて解釈します。

S/MIME

[3] S/MIMEUTCTime は 49‐50 が境界です RFC 3851 2.5.1

ISO/JIS 記憶媒体

[33] IS0 1001ISO 7665 では、2桁年号で00〜49に+2000, 50〜99に+1900して 解釈します。

PKIX

[12] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) <http://tools.ietf.org/html/rfc5280#section-4.1.2.5.1>

Conforming systems MUST interpret the year field (YY) as follows:

Where YY is greater than or equal to 50, the year SHALL be interpreted as 19YY; and

Where YY is less than 50, the year SHALL be interpreted as 20YY.

68-69を境界とする

X/Open の推奨

00〜68 → +2000, 69〜99 → +1900 を推奨しているらしいです。

69-70 を境界とする

[5] RFC 6265 が規定するCookieの日付形式の構文解析手続きにおいては、 69以下は2000年代、70以上は1900年代とされています。

38-39を境界とする

38年を境に、39年以降が1900年代にする実装が少なからずあります。 (一部の M$ 製品を含みます。) 根拠はよく分かりません。 (Un*x時間の32ビット限界の関係?)

すべて1900年代とする

[17] XPath and XQuery Functions and Operatorsfn:parse-ietf-date が採用しています。

不明

[18] TLEの日時形式

RFC 3339 の規定

[20] RFC 3339 は、インターネットプロトコル (Internet Protocols) に次のように要求しています。 >>19

作品

[30] 2000年問題作品

関連

[31] ISO 9660の日時形式は 1900年からの年数の8ビット符号なし整数を使っており、 2000年問題はありませんが、 0xFF 年までしか扱えません。

[26] 1万年問題も参照。

メモ

[13] RFC 2626 <urn:ietf:rfc:2626> は、それ以前に発行された RFC の仕様に存在する2000年問題を検証しています。

[1] Lotus Organizer 2000 は、利用者の入力を80年前〜19年後までの範囲内として受け取ります。

[2] Lotus 1-2-3 98 は、 >>1 の方法と「全部1900年代」を選べました。

[25] IBM Knowledge Center - EXEC CICS CONVERTTIME () <https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.1.0/com.ibm.cics.ts.applicationprogramming.doc/commands/dfhp4_converttime.html>

An older date and time stamp format for the Internet, specified in RFC 850. An example of a date and time stamp in this format is "Tuesday, 01-Apr-03 10:01:02 GMT".

Important

Because the year has only two digits in this format, CICS® uses the assumption that the years are in the range 1970 to 2069.

[27] “8年後に大地震”誤った地震速報配信で混乱広がる | NHKニュース (日本放送協会著, ) <http://www3.nhk.or.jp/news/html/20170622/k10011026911000.html>

地元メディアによりますと、USGSと提携している大学の研究者たちが、1925年6月にカリフォルニア州で起きた地震の情報を更新する作業中、データが誤ってUSGSに送信され、何かしらの原因で2025年の地震として配信されたと見られるということです。

[28] 桐ヘルプ - #元号日付 (管理工学研究所著, ) <https://www.kthree.co.jp/kihelp/index.html?page=fnc/fcnv_gdatestr&type=html>

日時文字列または日時型の定数として 2 桁以下の西暦年を指定すると、環境設定の [西暦年 2 桁入力時の取り扱い] に応じて年の値が加算されます。

西暦 1 年から西暦 99 年までの年を指定するには、年の前に西暦、AD、A のいずれかの文字をつけます。