/
125.txt
250 lines (164 loc) · 10 KB
/
125.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
[4] [[西暦]]が2桁または3桁の[[数字]]列で表されている場合、
これをどう解釈するかが問題となります。
各種の[[プロトコル]]や[[プログラム]]は色々な方針を採っています。
これが[DFN[2000年問題]]であり、[[桁溢れ問題]]の一種です。
[14] [TIME[2000年][year:2000]]は過ぎましたが、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]] もこれを踏襲しています。
[REFS[
- [7] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-7.1.1.1>
]REFS]
;; [11] [[HTTPの日時形式]]を参照。
** [CODE(perl)@en[Time::Local]]
[10] [[Perlモジュール]] [CODE(perl)@en[[[Time::Local]]]] は現在から前後50年以内と解釈します
[SRC[>>9]]。
[REFS[
- [9] [CITE[Time::Local - search.cpan.org]] ([TIME[2014-10-06 04:02:21 +09:00]] 版) <http://search.cpan.org/dist/Time-Local/lib/Time/Local.pm#Year_Value_Interpretation>
]REFS]
* 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/MIME]] の [CODE[[[UTCTime]]]] は 49‐50 が境界です
[SRC[RFC 3851 2.5.1]]。
** ISO/JIS 記憶媒体
[33] [[IS0 1001]] と
[[ISO 7665]]
では、2桁年号で00〜49に+2000, 50〜99に+1900して
解釈します。
;; [[記憶媒体の日時形式]]参照。
** PKIX
[FIG(quote)[
[FIGCAPTION[
[12] [CITE@en[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]]
([TIME[2015-02-22 15:44:10 +09:00]] 版)
<http://tools.ietf.org/html/rfc5280#section-4.1.2.5.1>
]FIGCAPTION]
> 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.
]FIG]
* 68-69を境界とする
** X/Open の推奨
00〜68 → +2000, 69〜99 → +1900 を推奨しているらしいです。
* 69-70 を境界とする
[5] [[RFC 6265]] が規定する[[Cookieの日付形式]]の構文解析手続きにおいては、
69以下は2000年代、70以上は1900年代とされています。
[REFS[
- [15] [CITE@en[MySQL :: MySQL 8.0 Reference Manual :: 12.3.3 The YEAR Type]] ([TIME[2017-03-10 16:49:06 +09:00]]) <https://dev.mysql.com/doc/refman/8.0/en/year.html>
- [16] [CITE@en[MySQL :: MySQL 8.0 Reference Manual :: 12.3.8 Two-Digit Years in Dates]] ([TIME[2017-03-10 16:50:50 +09:00]]) <https://dev.mysql.com/doc/refman/8.0/en/two-digit-years.html>
]REFS]
* 38-39を境界とする
38年を境に、39年以降が1900年代にする実装が少なからずあります。
(一部の [[M$]] 製品を含みます。)
根拠はよく分かりません。 ([[Un*x時間]]の32ビット限界の関係?)
* すべて1900年代とする
[17] [CODE[XPath and XQuery Functions and Operators]] の [CODE[fn:parse-ietf-date]]
が採用しています。
* 不明
[18] [[TLEの日時形式]]
* RFC 3339 の規定
[20] [[RFC 3339]] は、[RUBYB[[[インターネット]]の[[プロトコル]]]@en[Internet Protocols]]に次のように要求しています。
[SRC[>>19]]
- [21] [[プロトコル]]は、[[日付]]で4桁[[年]]を[[生成]]しなければ[MUST[なりません]]。
- [22] 2桁[[年]]は、[RUBYB[[[非推奨]]]@en[deprecated]]です。
受信時は、誤解釈が失敗につながらない場合 (例えば記録用にのみ使うような場合)
のみ受け入れるべきです。
- [23] 壊れた入力を受け入れる[[プログラム]]は、
3桁[[年]]に [N[1900]] を足しても構いません。
- [24] 壊れた入力を受け入れる[[プログラム]]は、
[CODE[:0]], [CODE[:1]], ..., [CODE[:9]], [CODE[;0]], ...
のように何も考えずに [[ASCII]] で十の位を増やしていった年号を意図した年と解釈しても構いません。
[REFS[
- [19] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2017-05-07 16:17:18 +09:00]]) <https://tools.ietf.org/html/rfc3339#section-3>
]REFS]
* 作品
[FIG(middle list)[ [30] [[2000年問題]]の[[作品]]
- [29] [CITE@ja[シュタインズ・ゲート ゼロ 第4話「亡失流転のソリチュード」 - ニコニコ動画]] ([TIME[2018-05-15 21:37:23 +09:00]]) <http://www.nicovideo.jp/watch/so33174199>
]FIG]
* 関連
[31] [[ISO 9660の日時形式]]は 1900年からの年数の[[8ビット符号なし整数]]を使っており、
[[2000年問題]]はありませんが、 0xFF 年までしか扱えません。
[26] [[1万年問題]]も参照。
* メモ
[13] RFC 2626 <urn:ietf:rfc:2626> は、それ以前に発行された
RFC の仕様に存在する2000年問題を検証しています。
[REFS[
- [8] <http://www.funaba.org/en/programming-and-calendar.html>
]REFS]
[1] [[Lotus Organizer]] 2000 は、利用者の入力を80年前〜19年後までの範囲内として受け取ります。
[2] [[Lotus 1-2-3]] 98 は、 >>1 の方法と「全部1900年代」を選べました。
[FIG(quote)[
[FIGCAPTION[
[25] [CITE@en[IBM Knowledge Center - EXEC CICS CONVERTTIME]]
([TIME[2017-05-18 00:31:31 +09:00]])
<https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.1.0/com.ibm.cics.ts.applicationprogramming.doc/commands/dfhp4_converttime.html>
]FIGCAPTION]
> 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.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[27] [CITE[“8年後に大地震”誤った地震速報配信で混乱広がる | NHKニュース]]
([[日本放送協会]]著, [TIME[2017-06-23 11:16:53 +09:00]])
<http://www3.nhk.or.jp/news/html/20170622/k10011026911000.html>
]FIGCAPTION]
> 地元メディアによりますと、USGSと提携している大学の研究者たちが、1925年6月にカリフォルニア州で起きた地震の情報を更新する作業中、データが誤ってUSGSに送信され、何かしらの原因で2025年の地震として配信されたと見られるということです。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[28] [CITE@ja[桐ヘルプ - #元号日付]]
([[管理工学研究所]]著, [TIME[2017-12-31 02:03:44 +09:00]])
<https://www.kthree.co.jp/kihelp/index.html?page=fnc/fcnv_gdatestr&type=html>
]FIGCAPTION]
> 日時文字列または日時型の定数として 2 桁以下の西暦年を指定すると、環境設定の '''['''西暦年 2 桁入力時の取り扱い''']''' に応じて年の値が加算されます。
> 西暦 1 年から西暦 99 年までの年を指定するには、年の前に西暦、AD、A のいずれかの文字をつけます。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[32] [CITE@ja[桐ヘルプ - 2桁年の扱いと西暦指定]]
([[管理工学研究所]]著, [TIME[2018-08-03 19:37:23 +09:00]])
<https://www.kthree.co.jp/kihelp/index.html?page=val/val_timestamp_yy&type=html>
]FIGCAPTION]
> 年を 0 ~ 99 の範囲で指定した場合、環境設定の設定に応じて自動的に 1900 年または 2000 年が補われます。
> 環境設定に左右されないように指定するには、年の前に 西暦、AD、A のいずれかの文字列をつけます。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[34] [CITE@ja[コンピュータ西暦2000年問題の概要|鈴木正朝|note]]
(鈴木正朝 2018/12/29 02:30 [TIME[2018-12-31 18:45:22 +09:00]])
<https://note.mu/rompal/n/n1a3d7e88232c>
]FIGCAPTION]
> Y2K対応は、95年末の時点では大問題なのかどうかも疑心暗鬼なところもあって、私一人が担当者となり細々と調査を開始した。予算もなく報告書を作る予定もなく、私的に手控え的に概要をとりまとめていたところ、目にとまって会報に掲載された。そのうちに社会問題として注目されるようになったことから、いくつかの業界誌等にも転載されることになり結果的に本邦初の報告書となった。
]FIG]
[35] [CITE@ja[ベンダからみたコンピュータ西暦2000年問題と1999年当時の企業法務|鈴木正朝|note]]
(鈴木正朝 2018/12/30 00:43 [TIME[2018-12-31 18:46:09 +09:00]])
<https://note.mu/rompal/n/nc2bb676df52e>