-
Notifications
You must be signed in to change notification settings - Fork 4
/
884.txt
186 lines (138 loc) · 8.62 KB
/
884.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
[1] [[計算機システム]]などの[[日時の処理]]では、
[[日時]]の構成要素が扱える (当初設計時に想定した)
[[値域]]を超えることがあり、問題となります。
[18] 設計時の想定では遠い[[将来の日時]]だったとしても、
思いの外そのシステムが長生きするのはよくあることです。
[19] 逆パターンはそれほど多くありませんが、
想定よりも応用が広がり、[[過去の日時]]の記述の必要が生じるという可能性もなくはありません。
-*-*-
[38]
情報交換用[[日時形式]]にせよ、情報処理用内部形式にせよ、
実用上は[[日時]]の記述に使うデータサイズに制限を設けざるを得ません。
制限を取り払ってどれだけでも[[過去の日時]]や[[将来の日時]]を表現可能にすると、
[[RFC 2550の日時形式]]のような扱いづらい形式になってしまいます。
[EG[
[39] [[CPU]] や[[プログラミング言語]]の[[整数型]]が64ビットの場合、
それより大きな[[整数]]を扱うには特別な処理が必要となります。
[[日時]]を大きな[[整数]]で扱うと、
近い日時の計算も含めてすべての[[日時]]計算が煩雑で低速になってしまいます。
]EG]
[22]
[[2000年問題]]への対処も、よくて9999年まで問題を先送りできたに過ぎませんでした。
実際には数十年程度の先送りで延命させたシステムも少なくありませんでした。
桁溢れ問題への本質的な対処は困難です。
* 年の桁溢れ
[5] 発症パターンとして、
- [13] [[値域]]の[[上限]]を超えて問題が起きる
- [6] 下2桁で扱っていたので、100年目に問題が起きる
- [7] [VAR[n]]年から99年を前世紀、0年から[VAR[n]]-1年を新世紀として扱っていたので、
二度目の[VAR[n]]年付近で問題が起きる
- [9] 0年や99年を特別な意味で使っていて問題が起きる
- [20] [[整列]]の順序がおかしくなる
... というのがあります。
[FIG(short list)[ [10] [[年号]]の[[桁溢れ]]の問題
- [[2000年問題]]
- [[10000年問題]]
- [[昭和100年問題]]
- [[民国100年問題]]
- [[2700年問題]]
- [[平成100年問題]]
- [[複数紀元詰め込み]]の問題
]FIG]
* 元号コードの桁溢れ
[2] [SEE[ [[元号コード]] ]]
* 整数時刻系の桁溢れ
[FIG(short list)[ [3] [[整数時刻系]]および[[時間]]変数の[[桁溢れ]]
- [[2036年問題]]
- [[2038年問題]]
- [[49.7日問題]]
- [[497日問題]]
- [[24.9日問題]]
- [[248日問題]]
]FIG]
[8] [[2010年問題]]、[[2020年問題]]、[[2021年問題]]のようにその他の[[値域]]制限に起因する場合もあります。
* 循環型日時系
[14] [[干支]]、[[GPS時]]など同じ名前の[[日時]]が一定期間経過後に繰り返される[[日時形式]]では、
当然ながら一周する期間を超えた範囲を扱うと[[日時]]を一意に識別できなくなります。
[EG[
[17] [[昭和]]は64年まであったため、
[[元号]]と[[干支]]だけでは[[年]]を一意に特定できません。
]EG]
[15] [[2000年問題]]や
[[100年問題]]もこの一種とも言えます。
* 整列
[4] 狭義の[[桁溢れ]]以外に、同じ[[桁]]数と仮定して[[文字列]]として[[整列][日時の整列]]させていたとき、
前提が崩れて順序がおかしくなるという問題が生じる場合もあります。
* その他
[11]
解釈の曖昧性が発生する[[賞味期限表示]]の[[2020年問題]]があります。
[24]
[[グレゴリオ閏日]]に関する[[2100年問題]]があります。
* 日時処理はどう設計するべきなのか
[25]
[[西暦2000年問題]]が深刻な社会問題となっていた頃、
それは古い[[計算機]]の資源が乏しかった故のやむを得ない制約だとか、
先見性のない技術者の落ち度だとかいろいろ言われていました。
[SEE[ [[西暦2000年問題]] ]]
[26]
[[西暦2000年問題]]の対策にはいろいろな手法がありました。
最も正当的とされた方法は[[年]]を2桁から4桁に変更するというものでした。
他に2桁のまま閾値を設けて1900年代か2000年代か切り分けたり、
[[西暦2桁年号]]のかわりに[[元号]]や[[皇紀2桁年号]]を使ったりする手法もあり、
特に前者は手軽な対策として相当広範囲で採用されたのですが、
それは場当たり的で解決を先送りしただけの、
悪い対策手法だという非難もありました。
[27]
そんな時代に風刺的に話題になったのが[[西暦10000年問題]]でした。
[[西暦2000年問題]]の対策で[[年]]を4桁化したところで、
所詮それも解決を西暦9999年まで先送りしたに過ぎないのです。
そんな先の時代まで今のシステムが動き続けるとは思えないでしょうか。
でもそれこそが、[[西暦2000年問題]]を引き起こした怠惰で先見性のない技術者達の判断ではなかったのでしょうか。
問題を本質的に解決するためには、
4桁化ではなく無限の[[未来][未来の日時]]まで扱えるような改修をしなければならないのではありますまいか。
[28]
現実的に考えて、
無限の[[過去][過去の日時]]から無限の[[未来][将来の日時]]まで、
無限の[[精度][秒の小数部]]で記述できる[[日時形式]]と[[日時処理]]システムというものは、
[[実装]]不能です。
* 関連
[21] [[旧暦2033年問題]]は性質が異なります。
* メモ
[FIG(quote)[
[FIGCAPTION[
[12] [CITE@ja[SHARP社製一部携帯電話をご利用中のお客さまへ大切なご案内 | スマートフォン・携帯電話 | ソフトバンク]]
(掲載日:2015年10月9日 最終掲載日:2016年1月14日 [TIME[2020-01-02 22:13:34 +09:00]])
<https://www.softbank.jp/mobile/info/personal/news/product/20151009a/>
]FIGCAPTION]
> カレンダー(日時設定)の機能制限により 2016年1月1日(金)以降日時表示が正しく表示できなくなります。2016年1月1日(金)以降も正しい日時表示でのご利用を希望されるお客さまは、機種変更されることをお勧めいたします。
> 2016年1月1日(金)以降、発着信履歴およびメール送受信時間等の時刻表示も正しく表示できなくなります。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[16] [CITE@ja[ケータイ電話のカレンダーの果てはどこまで? - エキサイトニュース]],
2009年8月20日 10:00,
[TIME[2020-11-28T05:12:19.000Z]]
<https://www.excite.co.jp/news/article/E1250562393684/>
]FIGCAPTION]
> 私のケータイのカレンダーは「2060年12月31日」までとなっている。あと51年!? は使える。一方、友人のカレンダーは「2030年12月31日」まで。差があるものだなーと思い、周りに聞いてまわったところ、以下のようになった。
> 2015年12月31日(SoftBank 912T)
> 2020年12月31日(au W61CA)
> 2030年12月31日(SoftBank 822SH)
> 2037年12月31日(Docomo SO705i)
> 2037年12月31日(Docomo P705i)
> 2060年12月31日(Docomo F882iES)
> 2099年12月31日(SoftBank 810P)
> 2099年12月31日(au mediaskin)
> 2099年12月31日(au W51SH)
> 9999年12月31日(au W64T)
> 9999年12月31日(au W54SA)
>
ケータイのカレンダーの長さに関して、Docomo・au・Softbankの三キャリアに質問メールを送ってみたが、おおむね「各端末メーカーの仕様になるので」という理由から、回答をいただくことができなかった。
>
では、と各メーカーに質問してみても、「各通信会社様がお問い合わせの窓口になりますので……」と、たらい回し状態。変な質問でお手数をかけ、申し訳ありませんでした。
>また、9999年までカレンダーが用意されている「超未来ケータイ」に関して、反対に気になったのが「始まりはいつなのか」という点。ひょっとして紀元1年とか…? 試してみると、1582年11月1日からカレンダーが始まっていた。
]FIG]
[23] この記事の筆者は「変な質問」と謙遜しているが、
製造・販売している側は答えられて当然の基本中の基本の仕様のはず。
それすらまともに答えられないのだから、
[[2020年問題]]や[[2021年問題]]を引き起こすのは必然だったということだ。