TidBITS-J#475/05-Apr-99 TidBITS-J#475/05-Apr-992000 年問題と Macintosh が気がかり？Mac OS は 2000 年問題に強いと聞 いたことがあるかもしれないが、Mac で稼働するローカルなデータベース や表計算、カスタムアプリケーションに 2000 年問題が無関係というわけ ではない。また、今週号では、Jeff Carlson が最新の TidBITS 御用達ツー ルで Default Folder を採り上げる。ニュースでは、Bare Bones 社が Mailsmith 1.1.3 をリリースし、Keyspan 社が Palm オーガナイザユーザー に向けて USB 対シリアルアダプタを出荷することをお伝えする。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：西村 尚 <hisashin@hotsync.co.jp>）
Palm 機に接続の USB アダプタ -- Palm オーガナイザのオーナーは、 HotSync クレードルを iMac や青白 Power Macintosh G3 マシンに接続す る USB の直接ソリューションがないことに不満を持っていたが、やっと Keyspan 社の 40 ドルの USB PDA Adapter を購入できるようになる。現 在、USB 対応 Mac のオーナーは USB 対シリアルアダプタと Palm Computing 社の MacPac アダプタを組合せて Mac 上のデータを Palm ハン ドヘルド機にシンクロさせる必要がある。USB PDA Adapter は Mac の USB ポートから Palm HotSync クレードルとスタンドアロンの HotSync ケーブ ルに見られる DB-9 シリアルコネクタに直接接続できるようにする。（Palm ハンドヘルドに関する詳細は、TidBITS の“Palm 研究”シリーズを参 照。）Keyspan によれば、この装置はシリアル接続の Wacom デジタルタブ レットでも使えるということだ。 [JLC]
<http://www.keyspan.com/products/usb/pdaadapter/>
<http://www.palm.com/macintosh/>
<http://db.tidbits.com/getbits.acgi?tbser=1030>
Bare Bones から Mailsmith 1.1.3 アップデート -- Bare Bones Software 社は、同社の高性能 POP/SMTP 電子メールプログラム、 Mailsmith のバージョン 1.1.3 をリリースした。バージョン 1.1.3 には、 ユーザーがリモートの POP サーバーからメッセージを選択してダウンロー ドまたは削除できるようにする新しい POP Monitor ウインドウと、メッ セージ中の引用テキストの操作の強化、Mailsmith のメール格納データベー スの改良、さらに一連のインターフェースの改良と特別付録が含まれる （完全な変更点リストを入手できる）。Mailsmith 1.1.3 アップデータは 3 MB のダウンロード容量で、現行の Mailsmith オーナーに無料である。 Mailsmith の価格は Bare Bones 直販で 79 ドルだが、BBEdit と BBEdit Lite のユーザーとさらに Qualcomm 社の Eudora あるいは Claris Emailer のオーナーは 59 ドルの割引価格を利用できる。無料の Mailsmith のデモ 版（3.6 MB）は Bare Bones の Web サイトからダウンドードできる。 [GB]
<http://web.barebones.com/products/msmith/msmith.html>
by Jeff Carlson <jeffc@tidbits.com>
（翻訳：尾高 修一 <shu@pobox.com>）
最近初期設定フォルダの中を探索したところ、ここ何ヶ月かの間にインス トールして結局外したユーティリティなどのプログラムの遺骸を発見する ことになった。こうして今は無用になった初期設定ファイルは、試してみ る価値はあったものの常用するには至らなかったアプリケーションの名を とどめている。それと同時に、システムフォルダを掘り進むうちに日頃忘 れがちなプログラムをもいくつか発見した。フォルダ階層の奥に埋もれて 顧みられなくなっているからではなく、その機能があたりまえと感じられ るようになっているからだ。このような逸品の一つに St. Clair Software 社の Default Folder がある。
<http://www.stclairsoft.com/DefaultFolder/>
Default Folder は従来型の「開く／保存する」ダイアログボックスと、よ り新しい Navigation Services ダイアログを拡張する。頻繁にアクセスす るフォルダに到達するために、Finder でファイル階層のディレクトリを一 つずつたどるということをする必要がなくなるのだ。その結果ファイルの 扱いがよりスムーズになるだけでなく、長期的には時間の節約にもなる。
Default Folder は「開く／保存する」ダイアログボックスの右上にある カレントなハードディスクの名前にポインタを持っていくと 4 つのボタン を並べて表示する。ボタンを押すとポップアップメニューが表示され、最 近使用したフォルダを選択したり、Favorites として登録したフォルダに アクセスしたり、マウントしてあるハードディスクを切り替えたり、 Default Folder のファイル管理機能を利用することができる。このうち 3 つのボタン、Favorites、Shortcuts（標準の「開く／保存する」ダイア ログにある Disks ボタンに似たもの）、それと Recent は Navigation Services ウインドウでは既に用意されている。Default Folder はこの左 側に独自の Utility ボタンを追加する。
Default Folder はアップルメニューに Favorites と Recent フォルダを 追加するとともに、Finder から階層の奥深くのフォルダに一発で到達する こともできるコントロールバーモジュールも用意している。
デフォルト自由自在 -- Default Folder の本領は、アプリケーション を使用する際に「開く／保存する」ダイアログから特定のフォルダにジャ ンプする機能にある。たとえば、FileMaker Pro データベースをすべて一ヶ 所のフォルダに保存するのであれば、このフォルダをデフォルトとして指 定する。Default Folder は使用するアプリケーション毎にデフォルトフォ ルダを指定することができるが、すべてのアプリケーションで使用するデ フォルトフォルダを指定することもできる。これによって誤ってファイル を保存してしまい、後でどこにあるかわからなくなるという事態を防ぐこ とができるのだ。以後はアプリケーションを起動後初めてファイルを開く か保存する際、このフォルダが自動的に選択されることになる。また、 Command + U を押すか、Favorites メニューの最初のアイテムを選んでそ のフォルダにジャンプすることもできる。Default Folder は最後に開い たか保存したファイルの位置を憶えておくので、指定したディレクトリへ 素早くジャンプすることによってデフォルトのフォルダへいちいち戻る手 間が省けることになる。
ディレクトリ指南 -- 私は同時に 4 〜 5 のプロジェクトを同時に手掛 けることが多いので、ほとんどの時間を数えるほどのフォルダで過ごすこ とになりがちだ。こうしたフォルダを Finder で全部開いておくこともで きるし、画面の下にポップアップウインドウとしておくこともできる。だ が常に使うもの以外をデスクトップに散らかしておくのは好きではないし、 ポップアップウインドウもすでに 5 つ並んでいる。
そこで私は通常使用するフォルダを「開く／保存する」ダイアログで Default Folder の Favorites メニューから選択してアクセスする。 Default Folder は良く使うフォルダに数字キーを使ったショートカット （たとえば Command + 2）を設定するため、これが私が圧倒的に多用する 機能となっている。ショートカットを変更することはできない（フォル ダが Favorites リストに現れる順番に基づいているため）が、Default Folder コントロールパネルでリストの順番を指定することができる。たと えば TidBITS 関連のファイルにアクセスする際にはどの「開く／保存す る」ダイアログでも Command + 1 を押す。この機能は基準となるポイント とすることにも使えるので便利だ。全く別のディレクトリまたはボリュー ムにいて、TidBITS と同じ階層にあるフォルダ（たとえば別のプロジェク ト）にジャンプしたい場合には、Command + 1 を押し、一つ上のフォル ダへ移動し、目的のフォルダを開けることができる。わずか 1 〜 2 分の セットアップで、いくつものステップからなる動作を 2 〜 3 のキースト ロークだけで済ませることができるようになった。私はキーボードから何 でもできるのが大好きなので、Default Folder がマウスへ手を伸ばす回数 を減らしてくれるのも嬉しい。
意外に手放せなくなったもう一つの機能として、「開く／保存する」ダイ アログが開いている時にデスクトップで開いているフォルダをクリックし てそのフォルダに移動するというものがある。デスクトップでウインドウ を開いておくことはなるべく避けるようにしているものの、使用中のディ レクトリのウインドウを開いておき、クリック一発で切り替えることがで きるのは便利だ。特に Finder のポップアップウインドウとの組み合わせ は便利で、画面下部のタブをクリックするだけでフォルダを見ることがで きる。この機能はアプリケーションの後ろで開いているウインドウでも有 効だ。
最新バージョンの Default Folder ではこの機能がさらに練られている。 「開く／保存する」ダイアログの外側でマウスをクリックしてボタンを押 し下げたままにしておくと、デスクトップで開いているフォルダをリスト したコンテクストメニューが表示されるのだ。
フォルダセット -- 複数のフォルダ間を何度も移動するということになっ ている場合は、Default Folder でフォルダセットを作成することが有効 だ。私は仕事で多数のフォルダを使うことがないので一つだけのセットを 使っているが、執筆関係の仕事とデザイン関係の仕事を分けるということ も考えられる。たとえば、一つの作業に集中しているときは関係ないアイ テムで Default Folder メニューを必要以上にちらかすことはしたくない。 こんな場合、Default Folder コントロールパネルで二つのセットを作成 し、それぞれのセットに該当するフォルダを登録することになる。複数の セットを使用する場合、Utility メニューを使うかキーボードから（たと えば Command + Option + 2 を押して）切り替えることができる。セット はインポート／エクスポートすることも可能だ。
その他水面下の機能 -- Default Folder はフォルダ間の移動に特化した ツールだが、ほかにも便利な機能が多数用意されている。「開く／保存す る」ダイアログから、フォルダの新規作成、ファイルやフォルダ名の変更、 それに Finder に出ずにアイテムをごみ箱に移動することができる。ファ イルのサイズ、作成・変更日、タイプ／クリエータ（これは Default Folder の上級モードで書き換えることができる）などといった情報にアク セスすることも可能だ。
カスタムアイコンを表示しないようにしてフォルダリストの表示を高速化 することもできる。このほかに、Recent メニューのサイズ、リストで Option キーを押しながらクリックしてどんな種類のファイルでも表示する 機能を追加したり、最近使用したファイルの表示を日付順・アルファベッ ト順で切り替える機能がある。Default Folder は Apollo、DragStrip、 DragThing、Dialog View、それに KeyQuencer といったユーティリティと 連携してディレクトリナビゲーション機能をさらに強化することができる。
<http://www.dcs.qmw.ac.uk/~jeremyr/apollo.html>
<http://www.poppybank.com/DragStrip/>
<http://www.dragthing.com/>
<http://members.aol.com/jwwalker/pages/dv.html>
<http://www.binarysoft.com/kqmac/kqmac.html>
少なくとも私の認識では、Default Folder は私の Mac と一体化している。 今や Default Folder の無いコンピュータを使うのは面倒で窮屈だ。作業 をしながら頭の中でディレクトリ構造を思い描かなければならず、本来の 作業に集中できないからだ。他のユーティリティ（たとえば Action Files、 TidBITS-434 の「ACTION Files の使命」を参照）には同様の機 能を持っているものもあるが、Default Folder はよりスリムでファイル周 りの作業をすべてやってのけようとするものではない。25 ドルのシェア ウェア料は使いだして数時間のうちに元が取れることだろう。ダウンロー ドサイズは 930K だ。
<http://db.tidbits.com/getbits.acgi?tbart=04931>
by Geoff Duncan <geoff@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
（ ：高島 均 <hitak@kk.iij4u.or.jp>）
ちょっと恥ずかしい話だが 1994 年の後半に TidBITS 入りして以来、受け 取った TidBITS 関係のメールはほとんどすべてとってある。当然、登録削 除や、休暇のお知らせ、ごみに類するような削除対象のメール以外のもの は、読者からのメッセージや TidBITS 内部でのやり取りを筆頭にほとんど すべて残してある。
このメールのアーカイブを覗くと、2000 年と Macintosh のついて 1995 年 2 月に一度話して以来書くのを避け続けていたということがわかる。そ の理由の一つには「2000 年問題」だの「千年バグ」だのさまざまな名前で 知られている Y2K の話がたいしておもしろいものに思えないということが ある。その影響は多岐にわたるものの、Y2K の件はコンピュータの計算上 の問題としてはあまりにも分かりきっていてつまらないし、Macintosh の ハードウェアおよびシステムソフトウェアは 2000 年を扱う際になんら問 題がないのだ。Y2K と Macintosh のことを記事にするのはハイウェーでの 運転の危険と車の話を書くのと同じようなことに思えた。この話題は大多 数の TidBITS の読者に直接かかわるかもしれないが、だからといってそれ が TidBITS を読む 理由 ではないのだから。
1995 年からすると事態は大きく変わっている。Y2K の話題はかつてはごく 一部の技術畑での話だったのが、今や新聞テレビ Web サイトが絶えず取り 上げる文化的話題の中心的存在になっている。意見や分析はさまざまであ る。破滅と地球規模の混乱を予想する専門家や、実際に山に逃げ込もうと している人たちがいる。その一方で、一部の専門家が Y2K はたいしたこと ではないかほとんど無に等しい問題であると言い、方や Y2K の大騒ぎは ユーザーや企業をうまくまるめこんで高いアップグレード料やコンサルト 費用を払わせようとする陰謀だと考える人たちがいる。さらに、相当な量 の Y2K の議論が、この問題がどれほど根深く、そして万人にかかわること だということを本当に知っている人が誰もいないことを如実に物語ってい る。Y2K に関するマスコミの報道は実にあいまいで、世紀末が近づくにし たがい人々の内で恐怖が募っているように見受けられる。
Apple 社は社会が世紀末の恐怖を増していくのをここぞとばかり、高慢な 発言で Web サイトで、そして 1999 スーパーボールのテレビ CM でさえも Macintosh が“Y2K 対応”であることを自慢しているのだ。
<http://www.apple.com/hotnews/features/hal.html>
Apple の高飛車な態度は歓迎されてはいないだろうが、言っていることは おおむね事実である。1984 年に登場した Macintosh 第一号機はマウス操 作を売りにしていたが、実際その時から世紀末対策はすでに行われていた。 しかし、Macintosh のハードウェアやソフトウェアが完ぺきな設計になっ ているからといって Macintosh ユーザーが自分のマシンは Y2K 問題とは 無縁であると必ずしも言い切れるわけではない。
Y2K とは -- まず、システムが 3 桁以上の年数の日付情報を正しく処理 できないということがこの問題の根本である。この定義は巷で信じられて いる Y2K 問題はコンピュータが 2 桁表示の年数を 1900 年代のものとし て解釈することに由来するというものと同じではない。つまり後者はシス テムがどのように 100 年以上の単位の情報を省略しているかということが この問題の一部になっている。反論する方もいるだろうが、“Y2K 対応” のプログラムは世紀情報を含めて日付を正確に処理するということだと私 は考えている。これは、あるプログラムに“01-Jan-00”と入力した時に 1900 年と解釈されて、むっとするなり非常に不都合だったりするだろう が、2 桁の年号表示というものは 100 以上の位をどんな数字にも容易にと られかねないということである（1200 年とでも 1600 年とでも 2300 年と でも）。私はこのこと自体は“Y2K 問題”だとみなしていない。プログラ ムが“01-Jan-2000”という入力を拒否したり、誤って解釈したりする時に 初めて問題になるのだ。前者はプログラムの認識と私の予測のずれが問題 なだけだが、後者は純粋にプログラムの日付処理に問題があるのだ。
人間は状況から年数の 100 以上の単位の部分を推測する。99 年 4 月 5 日の航空券と聞いて、常識で判断すると 1899 年のものだとは思わないだ ろう。実際ライト兄弟がキティーホークで初飛行を成功させたのは 1903 年のことだったのだから。話が同じ日付の列車の切符のことになると、価 格や印刷の字体、材質などの手がかりがないかぎり判断は難しくなる。
コンピュータは手がかりを探したりはしない。プログラマーの指示通りの ことを行うだけだ。プログラマーが「日付はすべて 20 世紀に属する」ま たは「世紀情報がない場合は 20 世紀として処理するように」とコンピュー タに教えているのが事実上大勢である。この場合プログラムが世紀情報を 保存しないというのが問題になる。これに影響されることは数多くある。 システムによってはクラッシュしたり、日付計算により予期しない結果が 出てそのために間違ったことを行ってしまうかもしれない。起動できない マシンもあるだろうし、データが壊れたり、100 年分の利子を請求される 人もいるかもしれない。さらには、日付情報を利用しているマイコン制御 を搭載したものが（大型汎用機からコーヒーメーカーに至るまで）あふれ ている今日では、どのシステムが年数の 3 桁以上の部分にかかわる日付問 題を抱えているか（および、それによりどんな問題が起こりうるか）を突 き止めるのは、途方もない作業だ。
プログラマーは何でこんなアホなミスをやらかしたんだと思うかもしれな い。しかしこれはあながちミスであるとは言えない。かつてプログラマー 達はメモリやストレージスペースを無駄にしないように余計な世紀情報を 外した。なにしろ、1970 年当時メモリ 1 メガが 300 万ドル以上したし、 その大きさはパンケースよりも大きくなったのだから。だが他方では、プ ログラマーたちは自分たちのつくったソフトウェアがその先 15 年、20 年、30 年も使われることになろうとは思いもよらなかったので、将来につ いてあまり考えていなかったというのも一つの真実である。さらには、プ ログラマーも所詮人間であり、過失だったとも言える。
Y2K と Mac -- Apple 社が製造している Macintosh のハードウェアとシ ステムソフトウェアは Y2K 対応である。つまり、Macintosh 内部でカウン トダウンしている「Y2K 時限爆弾」は基本的には存在しない。Apple の 出 している Y2K 準備関連の発表を確認するとよいだろう。また Y2K 問題に 関してテストした製品一覧も出ている。
<http://www.apple.com/about/year2000/>
Apple 社はそのおごった態度のために多少損はしているが、声明の基本的 な部分は、Mac には暦が 2000 年に変わる際の問題はないが、マクロや自 分で作ったプログラムを含めてサードパーティ製品に関してはなんら確約 はしない、ということである。要するに、他社製品の保証はできないが、 そういったものが Macintosh システムソフトウェアに内蔵されている日付 ルーチンを利用するようになっていれば（大部分の Mac プログラムがあて はまる）問題ないだろうということだ。古い Macintosh のソフトウェアは 1904 年 1 月 1 日から 2040 年 2 月 6 日 までの日付を処理することが でき、ここ 10 年内リリースされた Macintosh ソフトウェアはさらに幅広 に期間の日付を処理できる。すなわち、西暦で言うところの紀元前 30,081 年ぐらいから紀元後 29,940 年までに加えてグレゴリオ暦でないものも処 理できる。
Macintosh アプリケーションでありながら Mac OS の日付ルーチンを使わ ない代表的な例を 2 つ挙げると、大きな範囲で日付を扱わなければならな い場合と、別のオペレーティングシステム用に独自で開発した日付データ ないしプロセッサを使用しなければならない場合だ。これに当てはまるの は、（地質学や恒星の進化のような）とてつもなく長い時間の範囲を取り 扱うプログラムや、系図学、統計、ほかのプラットフォームと共有する日 付情報の読み書きをしなければならないような特殊な業界市場のためにつ くられたプログラムの Macintosh 移植版だ。もっともこれらは Macintosh うんぬんではない Y2K 問題になるだろう。
Y2K 対応ということで 頭に描いているもの はもっと別のことかもしれ ない。2000 年の声を聞いた途端に、下 2 桁の年号を 1900 年代のもとみ なす Macintosh プログラムがあるかもしれない。繰り返しになるが、プロ グラムが 4 桁の年号を拒否するなり、誤って解釈しないかぎりは、プログ ラムが壊れているとは言わない。もっともうっとうしいものではあるが、 ありがた迷惑のツールバーやショートカットキーのないよく使うコマンド と同じようなものだ。プログラムの中には、2 桁の年号の解釈について定 義できる「日付ウインドウ」がついているものもある。たとえば、System 6 と互換性を持たせるために、Apple の Date & Time コントロールパネル は今でもユーザーが 1920 年から 2019 年までしか入力できないように制 限されている。Microsoft Excel の現行バージョンは 4 桁の年数を処理す るが、29 以下の 2 桁の年号は 2000 年代、30 以上であれば 1900 年代だ とみなされる。同様に FileMaker Pro の現行バージョンも 4 桁の年数を 処理するが、年号が 2 桁の場合は今世紀と来世紀の境の前後 10 年が複雑 きわまりない処理が行われるようになっている。（それでも、式やスクリ プトで渡された 2 桁表示の年数をFileMaker が 1900 年代のものと解釈す ることは起こりうる。）
Macintosh Y2K 問題を取り扱っている包括的な情報センタは見つけられず にいるが、Rich Barron 氏が自分の Macnologist サイトで管理しているリ ストを見つけた。これは所々怪しい部分もあるが、手始めとしては使える だろう。アプリケーションについての情報は、その開発元にあたるのが一 番だろう（まだ健在ならばの話だが）。
<http://www.macnologist.com/y2k/>
でも Mac には免疫がある! -- Macintosh に関して Y2K 問題が発生する としたら、それは Mac OS やメジャーな商用製品からではなく、カスタム ユーティリティやカスタムアプリケーションからとなる可能性が最も大き い。デベロッパーならば大抵、Mac OS の内部的な日付処理能力を知ってい る。しかしながら、コンサルタント、趣味のプログラマー、教育実習生、 そしてありふれた Macintosh ユーザーたちは、その能力を知らないかもし れないし、確実にその能力にアクセスできるツールを持たないかもしれな い。さらに、これらの人々は必ずしも経験豊かなデベロッパーではないこ とから、数値エラーを起こしたり日付に関して誤った仮定をしてしまいが ちである。Mac OS や使用するツールが Y2K 対応であっても、古典的な Y2K 問題を呈するマクロや特製の解決法を作ってしまうことは全くもって起こ り得ることなのだ。
例えば、数ヶ月前に、ある地元の非営利団体から、以前在籍したボランティ アによって FileMaker Pro で数年前に開発された寄付金システムにおける “印刷トラブル”について、問題を特定し解決してほしいと頼まれた。そ のシステムは、その多くが定期的に寄贈してくれる支援者たちの約束に基 づいて、翌年中に見込まれる収入を予測するよう設計されていた。ところ が、システムは 1999 年より先の予測寄付金を印刷していなかったのだ。 「これは千年期に関するバグではないですよね?」と彼らは尋ねた。「だっ てまだ 1999 年の 1 月ですし! Mac は大丈夫なはずじゃなかったのですか?」
データベースを数分ながめてみると、典型的な Y2K 問題があることがわ かった。システムは寄付番号を寄付者の識別番号と支援レベルから作成し ていたが、この先頭に（ご想像のとおり）寄付が予期される月と年を付番 していたのだ。典型的な寄付 ID は、9904-4-1234 のごとくであり、ここ で“9904”とは期待する寄付の年と月を示している。これらの接頭番号は ソートのために使用されていた。つまり、システムは適切な予測を作成し ていたものの、ソートが正しく行われておらず、そしてデータベースを操 作する人間がそのことを発見する術を知らなかったということだったのだ。 質問を重ねてみて、彼らがその番号形式を選択したのはいろいろ考えた結 果であることが明らかとなった。それは、電話越しに読み上げるのが簡単 で、また 1950 年代にさかのぼる紙の帳票による集計システムでの寄付番 号とも一致するよう設計されていた。この問題を修正するのは簡単なこと だったが、その団体がベストと思われる変更を決定するまでには 2 週間を 要した。なぜなら、その番号はその団体の事業において広範に使用されて いたからだ。
この例は、FileMaker Pro のデータベースにおいて発生したものだ。しか し、同様の問題が、さまざまなツールを用いて製作されたカスタムソフト ウエアに存在し得る（し実際に存在している）。それらツールには、 HyperCard、SuperCard、AppleScript、FaceSpan、OneClick のようなユー ティリティプログラム、Microsoft 社の Visual Basic for Applications のような内蔵プログラミング言語が含まれ、またこれらに止まるものでは ない。それら自身はすべて Y2K 対応であるにもかかわらずだ! 同様に、 Excel や ClarisWorks のスプレッドシート計算式、Web ページに埋め込ん だ JavaScript スクリプト、あるいはあらゆるその他の場面において、ユー ザーが日付エラーを犯してしまうのはたやすい。
信頼の跳躍 -- 2000 年 1 月 1 日以降をのぞき見たい読者のために言っ ておくと、2000 年という年は閏年であるので、それゆえ日付に依存するシ ステムは 2000 年 2 月 29 日を扱う必要がある。ここでもまた、Macintosh はこの日を正しく扱うのだが、いくつかのコンピュータはそこでつまづい てしまう。事実、Connectix 社では、Virtual PC のエミュレーション・ク ロックチップがこの閏日を認識できないという理由によって、Virtual PC を 2.1.1（現行は 2.1.2）にアップデートしなければならなかった。
<http://www.connectix.com/html/vpc_updates.html>
グレゴリオ暦では、4 で割り切れる年を閏年としているが、その年が 400 で割り切れる場合を除いて 100 で割り切れる年は閏年としない。皮肉なこ とに、2000 年が閏年である事実が、自家製のユーティリティにとってトラ ブルにならないことがある。こうしたユーティリティは（もしそれらが閏 年を扱うようになっているとして）、大抵の場合 4 で割り切れる年を等し く閏年であると仮定しているからだ。このことによって、1900 年や 2100 年については誤って閏年であるとするのだろうが、2000 年に関しては正し いかのように振る舞うのだ。
<http://es.rice.edu/ES/humsoc/Galileo/Things/gregorian_calendar.html>
好奇心旺盛な読者のために言っておくと、Mac OS は閏秒については関知し ない（実際その他の主流デバイスやオペレーティングシステムでも同様だ が）。閏秒とは、原子時計が地球の回転と同期するために定期的に加えら れる調整のことで、それは一日に 2 ミリ秒の割合で遅れていく。
<http://maia.usno.navy.mil/eo/leapsec.html>
できうる限りの助言 -- Macintosh は、驚くほどに 2000 年に対する準 備が整っている。ほとんどの部分において、一般的な Macintosh ユーザー は心配することが何もない。
もし、特注の商用ソフトウエアを使用しているのなら、特にそれが他のプ ラットフォームから移植されたものであるなら、そのプログラムのベンダー に問い合わせて何らかの Y2K 問題に気づいているかを確認すべきだ。も し、自家製のマクロやカスタムソフトウエアに頼っているのなら、たとえ Y2K 対応ツールを用いて開発されたものであっても、2000 年の準備は大丈 夫か確認するか、もしくは自分の手でテストすべきだ。Y2K 問題に対する 基本的なテストの 3 点セットは、次のようなものとなるだろう。
Y10K -- 誰も何も言わなくても、そう、多くの Macintosh プログラム は、5 桁の年に適応するよう修正される必要がある。Mac OS はそれを全く 正しく扱えるとしてもだ。この問題については、 TidBITS-384730 で詳し く取り上げることを約束しよう。
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 