/
79.txt
148 lines (114 loc) · 8.25 KB
/
79.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
[240]
[TIME[西暦2020年][year:2020]]以後を正しく扱えない問題が何種類か報告されています。
[[2桁西暦年]]に起因するものも、そうでないものもあります。
-*-*-
[10]
「200102」のような[[賞味期限表示]]は、
[TIME[西暦2020年1月2日][2020-01-02]]とも、
[TIME[西暦2001年2月][2001-02]]とも解釈できます。
(更には、平成20年1月2日とも、
令和20年1月2日とも解釈できます。)
これが[[賞味期限]]や[[消費期限]]の[[2020年問題]]と呼ばれるものです。
[77] [[日本政府]]の[[消費者庁]]が示している[[賞味期限表示]]例には、
[[西暦2桁][2桁西暦年]]のもの、
[[元号の年数][元号年]]のみのものも含まれています。
[13]
製品ごとのいろいろな[[表記][日時形式]]が共存しており、
年の上位が省略されたり日が省略されることがあり、
しかも区切り文字が使われないことがある、
という環境から問題が生じています。
[11]
ただ現実的にはあまり問題にならないとされています。
[SEE[ [[賞味期限表示]] ]]
[5] 同じ原理で、[[ファイル名]]などの命名規則で問題が生じる場合があります [SRC[>>4, >>6]]。
機械的に生成され機械的に解釈されるなら、
命名規則が送受信者間で確実に共有されている限り誤解は生じませんが (普通はそうでしょう)、
生成と解釈の一方または両方が人間だったり、
命名規則が曖昧で慣習的なものだったりすると、
解釈に揺れが生じ得ます。
-*-*-
[2]
[[2000年問題]]に起因するとされるものも多数報告されています
[SRC[>>1, >>3, >>6, >>7]]。
[[2桁西暦年]]の解釈に関する[[2000年問題]]の対処として、
00年から19年までを +2000、20年から99年までを +1900
で解釈すると定めていた場合、
[TIME[2020年][year:2020]]以後を正しく扱えません。
[SEE[ [[2000年問題]] ]]
[12]
[TIME[2020年][year:2020]]という境界は
[[Unix epoch]]
たる
[TIME[1970年][0]]から50年と説明されるようですが、
深く考えずにそうしたのではないかと推測する人もいます。
[15]
[[Microsoft Excel 95]] は
20年を境界とする[[2桁西暦年]]解釈法を採用するため
[[2020年問題]]がありましたが、
[[Microsoft Excel 97]]
は
30年を境界に変更したため発症が10年先送りされました [SRC[>>14]]。
[SEE[ [[2000年問題]] ]]
-*-*-
[232]
その他にも問題が報告されています [SRC[>>201, >>200, >>199, >>239, >>8, >>9]]。
[REFS[
- [14] [CITE@en[[[Date windowing]] - [[Wikipedia]]]], [TIME[2020-01-12 00:07:56 +09:00]] <https://en.wikipedia.org/wiki/Date_windowing>
- [4] [CITE@en[2020年問題 - ♪ OKAWA Shigeki - Medium]], [[♪ OKAWA Shigeki]],
2008年4月10日,
Oct 30, 2013,
[TIME[2020-01-14 15:48:35 +09:00]] <https://medium.com/@geckyokawa/2020-605a2a124278>
- [201] [CITE@en-US[Splunk Announces Important Platform Update for the New Year]]
([TIME[2019-11-29 05:08:01 +09:00]])
<https://www.splunk.com/en_us/blog/bulletins/splunk-announces-important-platform-update-for-the-new-year.html>
- [200] [CITE@en[Timestamp recognition of dates with two-digit years fails beginning January 1, 2020 - Splunk Documentation]]
([TIME[2019-11-30 20:54:08 +09:00]])
<https://docs.splunk.com/Documentation/Splunk/8.0.0/ReleaseNotes/FixDatetimexml2020>
[FIG(quote)[
[FIGCAPTION[
[199] [CITE@ja[データ分析プラットフォームSplunk、パッチを適用しないと2桁表記された2020年以降の西暦年を認識できなくなる | スラド IT]]
([TIME[2019-11-30 20:53:16 +09:00]])
<https://it.srad.jp/story/19/11/30/0348212/>
]FIGCAPTION]
> 原因は入力データのタイムスタンプ認識に使用する正規表現の問題だという。問題の正規表現は「datetime.xml」というXMLファイルに含まれており、修正点を見ると「2」から始まる2桁表記の西暦年の存在が考慮されていなかったようだ。
]FIG]
- [239] [CITE@ja[【2020年問題】時間を刻めないガラケーが出始めたぞ - Togetter]], [TIME[2020-01-01 10:13:56 +09:00]] <https://togetter.com/li/1449851>
- [241] [CITE@ja[チカ@戻ってきたさんはTwitterを使っています: 「2020年問題起こしてるガラケーがソニーエリクソンモバイルコミュニケーションズ(SEMC)時代のKCP端末ばかり……」 / Twitter]], [TIME[2020-01-02 10:45:27 +09:00]] <https://twitter.com/00chicaa00/status/1212357209146871808>
- [8] [CITE@en[Y2K20 Parking Meter Software Glitch Causes Citywide SNAFU - Gothamist]],
[[Ben Yakas]],
Jan. 3, 2020 1:14 p.m.,
[TIME[2020-01-16 10:10:50 +09:00]] <https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-citywide-snafu>
- [1] [CITE@en-US[A lazy fix 20 years ago means the Y2K bug is taking down computers now | New Scientist]], [[Chris Stokel-Walker]],
7 January 2020,
[TIME[2020-01-14 15:41:40 +09:00]] <https://www.newscientist.com/article/2229238-a-lazy-fix-20-years-ago-means-the-y2k-bug-is-taking-down-computers-now/>
- [9] [CITE@en-US[Trimble requests extension to FMCSA repair mandate - FreightWaves]],
[[Linda Baker]], Wednesday, January 8, 2020,
[TIME[2020-01-16 10:14:57 +09:00]] <https://www.freightwaves.com/news/trimble-requests-extension-to-fmcsa-repair-mandate>
- [7] [CITE@en[Y2K quick-fix crick? 1920s come roaring back after mystery blip at UK's vehicle licensing agency • The Register]],
Richard Speed 13 Jan 2020 at 09:51,
[TIME[2020-01-16 09:58:56 +09:00]] <https://www.theregister.co.uk/2020/01/13/y2k_dvla/>
- [3] [CITE@ja[20年前の「2000年問題」の影響が時間を超えて各所で起こっているとの報告 - GIGAZINE]],
2020年01月10日 23時05分,
[TIME[2020-01-14 15:30:40 +09:00]] <https://gigazine.net/news/20200110-y2k-bug-taking-down-computers/>
-- >>1 が出典
- [6] [CITE@ja[年を2桁で処理するシステムの「2020年問題」 | スラド IT]], [TIME[2020-01-14 15:49:56 +09:00]] <https://it.srad.jp/story/20/01/14/1324235/>
-- >>1, >>3, >>4 が出典
]REFS]
[16] [CITE@ja[SIRATORI KazutakaさんはTwitterを使っています 「会社の契約書とか見ていて、いまが何年なのか考えちゃうんだよね。 ・官公庁や自治体との複数年契約では平成33年と出てきて、今は平成32年だから来年とやっと認識。 ・件名中に「2007」なんてあって2007年の誤記かと思いきや2020年07月。 いいかげん、西暦4桁で書きましょうや。」 / Twitter]]
([TIME[2020-07-14 19:35:35 +09:00]])
<https://twitter.com/gingakotei/status/1280505235404881920>
[17] [CITE@ja[今年の2000年問題(年2桁問題) | minetの日記 | スラド]]
(by minet 2020年08月11日 8時43分 [TIME[2020-08-11 18:26:21 +09:00]])
<https://srad.jp/~minet/journal/641001/>
[FIG(quote)[
[FIGCAPTION[
[18] [CITE@ja[ガラケーの時計が動かない 「2020年問題」の真相 :日本経済新聞]]
([TIME[2020-11-28T05:08:53.000Z]])
<https://www.nikkei.com/article/DGXMZO54065240W0A100C2000000/>
]FIGCAPTION]
>報告はいずれもKDDI(au)と沖縄セルラー電話が2000年代後半に発売したソニー・エリクソン・モバイルコミュニケーションズ(現ソニーモバイルコミュニケーションズ)製の端末に集中しているもようだ。06年に発売した「W43S」や07年発売の「W53S」、08年発売の「W64S」や同機種をベースにした「S002」のユーザーが、「時計が0時0分で止まった」といった症状をソーシャルメディアに投稿している。
> マニュアルの「日付・時刻の設定」の説明では、日付と時刻の入力範囲が「2000年1月1日から2019年12月31日まで」となっているからだ。当時のガラケーの機種変更のサイクルや3Gサービスの寿命などを考慮して、20年以降もこれらの機種が利用されることはないと判断した可能性がある。
]FIG]
[19] [[2000年問題]]の教訓はこの頃にはもう忘れられていたのか!
[20]
そして毎年の恒例行事になるのでしょうか → [[西暦2021年問題]]