/
243.txt
149 lines (104 loc) · 9.3 KB
/
243.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
[4] [[グレゴリオ閏日]]たる
[TIME[2月29日][--02-29]]の扱いをめぐる問題は恒常的に起こっています。
[SEE[ [[閏年]] ]]
[10]
[TIME[平成12(2000)年][2000-02-29]]は[[西暦2000年問題]]の絡みもあって特に大問題となりました。
-*-*-
[11]
[TIME[西暦2000年][2000]]は[[グレゴリオ置閏法]]では4年に1回の[[閏年]]になるところ、
100年に1回の特例で[[平年]]になると思わせて、
400年に1回の特例で[[閏年]]となる[[年]]でした。
-
[9] [CITE[2月29日に関する政府の対応について]], [TIME[2021-03-05T03:53:19.000Z]], [TIME[2000-08-23T19:38:50.427Z]] <https://web.archive.org/web/20000823193821/http://www.kantei.go.jp/jp/pc2000/2000/02-29haridasi.html>
-
[8] [CITE@ja[2000年問題 - Wikipedia]], [TIME[2021-02-18T07:40:50.000Z]], [TIME[2021-03-05T03:52:39.634Z]] <https://ja.wikipedia.org/wiki/2000%E5%B9%B4%E5%95%8F%E9%A1%8C#2000%E5%B9%B42%E6%9C%8829%E6%97%A5>
[12]
[TIME[西暦2000年][2000]]が[[平年]]判定される問題が実際に起こったシステムでは、
どのような現象があったのでしょうか。
- [13] [TIME[西暦1900年][1900]]と誤認され、[[グレゴリオ置閏法]]により[[平年]]と判断された?
-- [24]
主要部は改修されて無事[TIME[西暦2000年][2000]]を迎えたが、
[[置閏法]]実装部だけ改修漏れというのは、あり得なくはない?
- [14] 4年に1回[[閏年]]、ただし100年に1回[[平年]]、の中途半端な[[置閏法]]が実装されていた?
-- [23] そんなことあり得るのか?
- [20] そもそも[[置閏法]]が実装されていなかった?
-- [21] 4年以内に新設または改修されたシステムなら、あり得なくもないが、あり得るのか?
-- [22] [[21世紀]]に入ってから報告された[[閏年バグ]]の数を考えれば、
あり得るのかも?
[19] [[ユリウス置閏法]]を実装していたなら、[TIME[西暦2000年][2000]]は正常に[[閏年]]判定されていたはず。
(その場合何も問題が起こらないので観測不可。報告されていないだけでこのケースはかなりありそう。)
-*-*-
[1] [CITE[今年が『うるう年』だってことを忘れていて、公式サイトを間違えて1日早くオープンしちゃった美少女ゲームブランド「地雷ソフト」が色々と凄い:【2ch】ニュー速VIPブログ(`・ω・´)]]
( ([TIME[2012-02-29 07:50:32 +09:00]] 版))
<http://blog.livedoor.jp/insidears/archives/52530052.html>
[15] [CITE[グレゴリオ暦/ユリウス暦 ⇔ ユリウス日 (または一般の通算日数) 変換アルゴリズム]]
( ([TIME[2014-06-07 06:20:30 +09:00]] 版))
<http://www5d.biglobe.ne.jp/~noocyte/Programming/GregorianAndJulianCalendars.html#DayNumbers>
[16] [CITE@ja[Excel の 1900 年を基準とした日付方式と 1904 年を基準とした日付方式の違いについて]]
([TIME[2015-05-09 10:53:45 +09:00]] 版)
<https://support.microsoft.com/ja-jp/kb/214330/ja>
[17] [CITE@ja[1900 年 3 月 1 日の前に曜日が Excel で正しくないです。]]
([TIME[2015-05-09 10:54:16 +09:00]] 版)
<https://support.microsoft.com/ja-jp/kb/214058>
[FIG(quote)[
[FIGCAPTION[
[18] [CITE[【228】Perl での紀元前の日数計算をもうちょっと調べる… - 分室の分室]]
([TIME[2015-12-14 14:40:59 +09:00]] 版)
<http://d.hatena.ne.jp/foussin/20120421/1334936160>
]FIGCAPTION]
> 紀元前1年(西暦0年) 2月29日から、日付が 1日ズレている。紀元前 1年を閏年
> とするのは、まあ分かるんだけど。。。
> 【重要】
> ただ、ズレた日付の曜日は、正しい曜日になっている。なので、当面の措置と
> しては『0年2月29日より昔の日付』は、日数を -1 してから timegm() に渡す…
> という修正をするしかないかな
]FIG]
[FIG(quote)[
[FIGCAPTION[
[25] [CITE[SCEがPSN関連のPS3不具合について状況報告~24時間以内の解決を約束 - わぱのつれづれ日記]]
([TIME[2016-07-26 08:19:41 +09:00]])
<https://d.hatena.ne.jp/wapa/20100302/1267469183>
]FIGCAPTION]
> 先のエントリのP.S.5のところで引用した上記の記事を考察すると、どうも問題を起こす機種は、現在の日付を「2/29」とうるう年と誤認しており、結果として無効な値をOS側に返している可能性があるようです。このため、OSが無効な日付だと認識し、結果システムの時刻を初期値である2000/1/1に戻しているのではないかと。また、そうした無効な日付の値から、PSNのサービスでも「致命的エラー」と判定してエラーコードをだしているのかもしれません。
> 一応、日本時間の3/2午前9時になれば、PCなどの機械で時計管理に広く用いられているグリニッジ標準時(GMT)でも3/2になり、内部のシステムが一応有効な日付を返してくる可能性があります。そうなれば、あとはサーバー側の手続きで対応可能、ということなのではないかと思われます。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[26] [CITE[ソニー、ウォークマンAのワンセグ“うるう年問題”を改善]]
([TIME[2016-12-11 18:35:12 +09:00]])
<http://av.watch.impress.co.jp/docs/20080422/sony2.htm>
]FIGCAPTION]
> 対象機種はNW-A916/A918/A919の3製品。これらのモデルでは、うるう年の2月29日に番組表の時刻表示が「**:**」と表示されて録画予約が行なえず、「この番組を録画」で録画しようとすると、「番組の終了時刻が取得できませんでした。8時間録画します」と表示され、録画が開始されるという問題が発生していた。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[28] ([TIME[2001-11-11 14:06:55 +09:00]])
<http://cr.yp.to/proto/utctai.html>
]FIGCAPTION]
> Fortunately, the POSIX rules are so outrageously dumb---for example, they require that 2100 be a leap year, contradicting the Gregorian calendar---that no self-respecting engineer would obey them.
]FIG]
[34] [CITE@ja[Sho Ikedaさんのツイート: "そういえば去年面白かったバグで、とある有効期限チェックで、2019年8月から半年後の月末が2020年2月末、つまり閏年なので2月29日になるのだけど、よくある和暦バグと組み合わさって令和2020年2月29日と解釈しようとして、令和2020年は閏年ではないのでパースに失敗する、ということがありました。"]]
([TIME[2020-01-06 12:06:54 +09:00]])
<https://twitter.com/ikesyo/status/1212197835040419840>
[32] [CITE['''['''tz''']''' tzcode history (was: Re: Java & Rearguard)]]
([TIME[2019-06-05 01:49:06 +09:00]])
<https://mm.icann.org/pipermail/tz/2019-June/028060.html>
[2] [CITE['''['''tz''']''' Leap year bugs]]
([TIME[2020-01-23 03:37:47 +09:00]])
<https://mm.icann.org/pipermail/tz/2020-January/028811.html>
[3] [CITE@en[The hassles of being a leap year baby - National | Globalnews.ca]]
(BY MICHELLE MCQUIGGE THE CANADIAN PRESS Posted February 25, 2016 9:07 am Updated February 25, 2016 9:10 am [TIME[2020-01-26 19:10:22 +09:00]])
<https://globalnews.ca/news/2539442/the-hassles-of-being-a-leap-year-baby/>
[5] [[2100年問題]]
[6] [CITE@ja[前任者から引き継いだシステム、うるう年なのに何故か2/29が表示されないと思ったらとんでもない設計になっていた件 - Togetter]]
([TIME[2021-03-05T03:36:11.000Z]])
<https://togetter.com/li/1677147>
[7]
[[グレゴリオ置閏法]]が複雑だから[[閏年]]は何年とハードコードしとこう、
とアドバイスしてるのどこかで見たことある、どこだっけなあ。
[27] [CITE@ja[ソフトウェア技術者のためのバグ百科事典(1)うるう年:山浦恒央の“くみこみ”な話(122)(2/3 ページ) - MONOist]], [TIME[2021-06-29T03:15:39.000Z]] <https://monoist.atmarkit.co.jp/mn/articles/1910/08/news012_2.html>
[29] [CITE@ja[ソフトウェア技術者のためのバグ百科事典(1)うるう年:山浦恒央の“くみこみ”な話(122)(3/3 ページ) - MONOist]], [TIME[2021-06-29T03:16:05.000Z]] <https://monoist.atmarkit.co.jp/mn/articles/1910/08/news012_3.html>
[30] [CITE@ja[ソフトウェア技術者のためのバグ百科事典(2)まだあるぞ、うるう年バグ:山浦恒央の“くみこみ”な話(123)(1/3 ページ) - MONOist]], [TIME[2021-06-29T03:16:30.000Z]] <https://monoist.atmarkit.co.jp/mn/articles/1911/07/news013.html>
[31] [CITE@ja[ソフトウェア技術者のためのバグ百科事典(2)まだあるぞ、うるう年バグ:山浦恒央の“くみこみ”な話(123)(2/3 ページ) - MONOist]], [TIME[2021-06-29T03:16:45.000Z]] <https://monoist.atmarkit.co.jp/mn/articles/1911/07/news013_2.html>
[33] [CITE@ja[ソフトウェア技術者のためのバグ百科事典(2)まだあるぞ、うるう年バグ:山浦恒央の“くみこみ”な話(123)(3/3 ページ) - MONOist]], [TIME[2021-06-29T03:17:11.000Z]] <https://monoist.atmarkit.co.jp/mn/articles/1911/07/news013_3.html>
[35] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2022-12-28T01:04:23.000Z]], [TIME[2023-01-01T10:08:47.630Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2010>