アカウント名:
パスワード:
MS-Officeは、日付のデータを、1900年1月1日からの通算で内部表現しているそうだけど、1900年が本来はそうじゃないのにうるう年(leap year)であると認識するバグを持っていて、それがずっとひきずられているらしい。
http://support.microsoft.com/default.aspx?scid=kb;ja;JP106339 [microsoft.com]
つまり、1900年3月1日以降において、真面目に1900年1月1日から積算した日付と、MS-Excel内部の日付には1日のズレがある(通算日数と年月日の対応関係では、Excelは自動的に-1するようになっているから、見掛け上は問題にはなっていないだけ...そのかわり、1900年2月28日以前の対応がズレているけどそれは放置されている)。で、さらにすごいのが、このバグ(仕様?)が、新しいOpenXMLフォーマットの仕様にまで入っていること。つまりMicrosoft社は、自社のMS-Excelで糊塗しているバグを直さず、かわりにそれを「オープンな仕様」にしようとしている。
こんな仕様、信用できますか?人類の歴史は、MS-ExcelもしくはOpenXMLフォーマットで記載されるものはすべて、「1日だけずれるのかどうか?」というambiguityを抱えることになる。日米開戦の日付が日付変更線のあちらとこちらで違うというレベルの話でなく、下手したら、ほんとに1日ずれちまうんだよ。それでいいの?
http://www.robweir.com/blog/2006/10/leap-back.html [robweir.com]
Microsoft Excelの元プログラムマネージャJoel Spolsky氏の「 はじめてのBillGレビューのこと [joelonsoftware.com]」をどうぞ。
1900年はうるう年ではない。 「これはExcelのバグだ!」 私は興奮した。 「実際はそういうわけじゃない」とエドが言った。「Lotus 123のワークシートをインポートできるようにするために、そうする必要があったんだ」 「じゃあ、Lotus 123のバグってこと?」 「そう。だけどおそらくは意図的なものだ。Lotusは640Kのメモリに詰め込む必要があった。これはあんまり大きなものじゃない。 1900年を無視すれば、与えられた年がうるう年かどうか判定するのは右端の2ビットが0かどうか見るだけで済む。そのほうがずっと早くて簡単だ。たぶん Lotusの連中ははるか昔のふた月が間違っていたところで問題にはならないと考えたんだろう。一方でBasicの連中は、そのふた月にこだわってエポックを1日ずらしたんだ」 「あーっ!」私は声を漏らした。そして「1904年から計算する」というチェックボックスがオプションダイアログについている理由を知ったのだ。 その翌日がBillGレビューの日だった。
Funny, when I worked at Lotus the story I heard was the bug was originally there for compatibility with VisiCalc...
しかしこのコメントはもっと面白いな。http://www.robweir.com/blog/2006/10/leap-back.html#3022317665572988689 [robweir.com] Funny, when I worked at Lotus the story I heard was the bug was originally there for compatibility with VisiCalc...
この強迫的なまでの後方互換性が人々にWindows 95にアップグレードしたいと思わせたのだ。
人類の歴史
1904年以前の事象しか扱わないプログラムなりデータベースを作っているならいいでしょうが、標準化されるってことはその規格でずっと使われるってことです。
最初に間違えた人が誰でもいいですが、これだけはっきりした間違った挙動を正式規格に入れることは止めて欲しいです。2000年問題だって、あれだけ分かりやすいルールでも結構問題になりましたよね。運用でカバーというのはこの問題では、所詮その場しのぎだと思います。
今だったら、被害は過去の資産由来のExcelファイルのわずかで済みます。最悪、コンバートするとか、気がついたら直すでもいい。100年前の日食の記録とかをExcelで管理しているとかいう人にとってはたまったものではないだろうけど、でも規格になっちゃったら、将来すべての実装者がその訳が分かんないbugを再現しなきゃいけないんです。それはいくらなんでも今後ソフトウェア技術者が払うペナルティーが大きすぎます。賛成できません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
うるう年の問題 (スコア:2, 興味深い)
MS-Officeは、日付のデータを、1900年1月1日からの通算で内部表現しているそうだけど、1900年が本来はそうじゃないのにうるう年(leap year)であると認識するバグを持っていて、それがずっとひきずられているらしい。
http://support.microsoft.com/default.aspx?scid=kb;ja;JP106339 [microsoft.com]
つまり、1900年3月1日以降において、真面目に1900年1月1日から積算した日付と、MS-Excel内部の日付には1日のズレがある(通算日数と年月日の対応関係では、Excelは自動的に-1するようになっているから、見掛け上は問題にはなっていないだけ...そのかわり、1900年2月28日以前の対応がズレているけどそれは放置されている)。で、さらにすごいのが、このバグ(仕様?)が、新しいOpenXMLフォーマットの仕様にまで入っていること。つまりMicrosoft社は、自社のMS-Excelで糊塗しているバグを直さず、かわりにそれを「オープンな仕様」にしようとしている。
こんな仕様、信用できますか?人類の歴史は、MS-ExcelもしくはOpenXMLフォーマットで記載されるものはすべて、「1日だけずれるのかどうか?」というambiguityを抱えることになる。日米開戦の日付が日付変更線のあちらとこちらで違うというレベルの話でなく、下手したら、ほんとに1日ずれちまうんだよ。それでいいの?
http://www.robweir.com/blog/2006/10/leap-back.html [robweir.com]
Re:うるう年の問題 (スコア:2, 興味深い)
Microsoft Excelの元プログラムマネージャJoel Spolsky氏の「 はじめてのBillGレビューのこと [joelonsoftware.com]」をどうぞ。
Excel ← Lotus ← VisiCalc? (スコア:1, おもしろおかしい)
http://www.robweir.com/blog/2006/10/leap-back.html#1114765182089629266 [robweir.com]
#1108545は参照したという記事を本当にちゃんと読んで投降しているのだろうか?
しかしこのコメントはもっと面白いな。
http://www.robweir.com/blog/2006/10/leap-back.html#3022317665572988689 [robweir.com]
Re:Excel ← Lotus ← VisiCalc? (スコア:0)
VisiCalc作った奴、出て来い!(笑
Re:Excel ← Lotus ← VisiCalc? (スコア:2, 参考になる)
ご本人のサイトもあります [danbricklin.com]。VisiCalcもダウンロードできます。
※VisiCalcで検索したら、略称のDanのままの表記のサイトが多いけど、
本名はDaniel。ビルゲイツの本名がウィリアム何とかVer.3って長い名前なのと同じ。
で、Wikipediaの記事 [wikipedia.org]にあるように、
他社が思いっきりタダ乗りしていたのなら、「バグ」の槍玉にあげる権利はないよなと思います。
Re:うるう年の問題 (スコア:1, 参考になる)
それをまだ入れるかどうかというのは議論の余地が有るかもしれないですけど。
joel on software MSの後方互換性 (スコア:1)
http://japanese.joelonsoftware.com/Articles/StrategyLetterII.html [joelonsoftware.com]
>Microsoftはそのバグを追いかけ、Windows 95にSimCityを検出するコードを追加した。
>それがSimCityが実行されているのを見つけると、それはメモリをすぐには開放しない
>特殊なモードでメモリアロケータを実行するのだ。この強迫的なまでの後方互換性
OOXMLの話も含めてここまでいくと、正しいんじゃなくてその姿勢は間違ってると言いたくなる。
Re:joel on software MSの後方互換性 (スコア:1)
その記事が論じているのは、つまるところ、「Microsoft のそのやり方はなぜ成功したか」です。元引用で最後に切られている次文章の通り。
Microsoft の流儀なら、ODF が既に普及した規格であれば、後方互換性であわせてくると思います。
ODF と OOXML はどちらも普及どころかまだ定着もしていない規格だから、Microsoft は自分が作った仕様をよかれと主張していると思います。
Re:joel on software MSの後方互換性 (スコア:1)
>自分が作った仕様をよかれ
のよかれの中に、一般規格には非常識と言える自分のバグを仕様化した、MS社内のみ有効な後方互換への強要が含まれるわけでしょ。
一般へのよかれならうるう年バグを含むハズがないよね。
あくまでMS社内へのよかれで。
もっとMSにはその非常識規格を提案する権利がある事はあるんだろうけどね。
あくまで権利の行使だけであって、一般へのよかれじゃないよね。
じゃその「バグを含んでよし、個々の実装でいちいち回避すれば」を前提として提案しちゃうような一般には不可解なMS流儀はどこから来たのか?
ちゃんとストーリーはつながりますよ。
Re:joel on software MSの後方互換性 (スコア:0)
「そんな変なデータは切り捨てるべきだ」
という意見もあるだろうし
「変なデータかもしれないが使えるようにしてほしい」
という意見もあるでしょう
home_cardさんの「常識」では切り捨てる方を選択するのが当たり前でも、
それが一般の人の「常識」かというと、どうなんでしょうね。
Re:うるう年の問題 (スコア:0)
再実装の問題 (スコア:2, 興味深い)
1904年以前の事象しか扱わないプログラムなりデータベースを作っているならいいでしょうが、標準化されるってことはその規格でずっと使われるってことです。
最初に間違えた人が誰でもいいですが、これだけはっきりした間違った挙動を正式規格に入れることは止めて欲しいです。2000年問題だって、あれだけ分かりやすいルールでも結構問題になりましたよね。運用でカバーというのはこの問題では、所詮その場しのぎだと思います。
今だったら、被害は過去の資産由来のExcelファイルのわずかで済みます。最悪、コンバートするとか、気がついたら直すでもいい。100年前の日食の記録とかをExcelで管理しているとかいう人にとってはたまったものではないだろうけど、でも規格になっちゃったら、将来すべての実装者がその訳が分かんないbugを再現しなきゃいけないんです。それはいくらなんでも今後ソフトウェア技術者が払うペナルティーが大きすぎます。賛成できません。
vyama 「バグ取れワンワン」
Re:再実装の問題 (スコア:0)
Re:再実装の問題 (スコア:0)
これをその場しのぎとして忌み嫌うか、それとも必要な処置だと考えるかは人それぞれですね。
過去のしがらみが本当にないのであれば、それこそ、革命的なシステムが作れるかもしれませんが、良くも悪くも、それが下位互換性であり、今必要とされていること何ですyね。
話のスケールが変わりすぎると言われるかもしれませんが、今ある数々の規格の中にも、バッドノウハウまみれで、誰もが、そんな歴史をすっぱりと切り捨ててしまった方が良いと思っているものなんて腐るほど有りますよね。
私が思いつく限りでも、
・QWERTY
・POSIX
・Shift JIS
・Windows/DOS
・IPv4
・AJAX
・・・挙げ出すときりがない。
Re:再実装の問題 (スコア:0)
きめて きめて
美しいけれど誰も使わないSpec と 醜いけどみんなが使っている事実
選びたいのはどっち?