システムが2010年を理解できなかったという報告はたくさんありますが、その理由はわかりません。私が管理している現在のシステムは、私が知る限り正常に機能していますが、実際の問題は検索を改善することです。
誰かがそれに光を当ててもらえますか?
編集:http ://www.rte.ie/business/2010/0105/bug.html-ドイツのクレジットカードに影響を与える情報
銀行や電気通信で使用されるいくつかのプロトコル(SMSプロトコルを含む)は、年を1バイトのBCDとしてエンコードします。
2000〜2009年の場合、エンコーディングは同じであるため、年を標準の2進数として解釈するという間違いを簡単に犯す可能性があります。
Encoding Binary-interpreted BCD-interpreted
0x01 2001 2001
0x02 2002 2002
...
0x09 2009 2009
0x10 2016 2010
...
これがおそらくWindowsMobileのバグの原因です。
考えられる説明の1つは、以下の記事にあります
http://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
2000 年の安っぽく汚いバグ修正についてのあなたの最近の記事を思い出します。この記事では、何人かの不謹慎なプログラマーが単純な if <10 = 20xx でなければ、日付は 19xx になります。
SpamAssassin には、あまりにも未来の日付をスパムとしてマークするルールがありました。
/20[1-9][0-9]/
修正は数日遅れましたが、非常に簡単です。
/20[2-9][0-9]/
また十年後に会いましょう。
I took care of a little 2010 fail in a site last weekend, it was just the result of an oversight in coding though.
Someone thought it would be a good idea to set the value of a list item to the current dateTime.year.Now() when the list only contained items up to 2009.
ddlItem.findByText(DateTime.Now.Year.ToString())
1 桁の年フィールドを使用するシステムを使用しています。はい。一桁。つまり、このシステムが失敗している理由は、「2000」が「2010」と同じように表現されているからです。
私が聞いたのは、2000 年問題についてよく考えずに人々が行った簡単な修正でした。したがって、xx < 10 の場合は 20xx、それ以外の場合は 19xx です。
これは、2000 年以降にキャリアをスタートさせた若い開発者が年を表すのに 1 桁を使用しているためかもしれません。
これがノートンライフロックのエンドポイント保護のスクリーンショットです
代替テキストhttp://img695.imageshack.us/img695/4500/152010112800am.jpg
@ symantecが顧客に通知しなかったのは本当に素晴らしいことです...記事が投稿されるまで:http ://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
年を 2 つに分割するコンポーネントにバグがあるということです。2 番目の部分は比較で使用されるため、数字 10 は基数 10 ではなく基数 16 であり、0x10 = 16 (16 進数) であることを意味します。
Google Code Search を使用して、オープン ソース ソフトウェアの 2010 年のバグを見つけました。バグを示す特定のパターン (printf フォーマット文字列として "200%d" を使用) を探したところ、そのバグを持つプロジェクトがいくつか見つかりました。検索パターンを創造的に適用することで、さらにさまざまな種類のバグが見つかる可能性があります。