← 2026-03-08 の一覧へ戻るホーム
**「タイムゾーンデータベースの驚きとユーモア」**

2026/03/08 3:32

**「タイムゾーンデータベースの驚きとユーモア」**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

日本語訳：

ブリティッシュ・コロンビア州が最近恒久的な夏時間（DST）に切り替えたことは、ソフトウェア開発者やスケジューリングシステムが正確な時刻を維持するために依存している主要なリソースである IANA タイムゾーンデータベースに正式に追加されました。変更内容はデータベースのニュースファイルに記録され、全世界のタイムゾーン調整を追跡する公開 

tz
GitHub リポジトリで新しいコミットとして確認できます。このリポジトリには、第二次世界大戦中のイギリス「ダブルサマータイム」や過去の夏時間実験に関する遊び心ある逸話など、多くの歴史的エントリーが豊富に含まれており、時刻規則がどのように進化してきたかを示しています。今後もデータベースはブリティッシュ・コロンビア州の恒久的なオフセットを反映し続け、人間にとって理解しやすいタイムゾーン歴史のノート集を維持します。正確なタイムスタンプに依存するソフトウェア（開発者、カレンダーサービス、物流プラットフォームなど）を構築または保守している人々にとって、この変更は地域内で固定された1時間の差分を考慮したアルゴリズムへの調整を意味します。

本文

タイムゾーンは扱いが難しいものです。ある有名なComputerphile動画では、こう語られています。

タイムゾーンを学んだ後に分かることは、実際にはコードを書き続けるのではなく、そのコードを「置いておく」しかないということです。自分より前にこの問題に取り組んできた人々―最初に対処した者たち、スパゲッティコードを作り出した者たち―を見て感謝し、オープンソースであることに敬意を表します。そして彼らが作ったものを自分のプログラムに取り込んで、それ以降は再び手を触れないようにしましょう。そうすれば狂気から遠ざかる道です。

最近、カナダ・ブリティッシュコロンビア州は恒久的な夏時間（Permanent Daylight Time）への移行を決定しました。この変更が IANA タイムゾーンデータベースに反映されているか確認したいと思いました。幸いにも、このデータベースの更新内容は GitHub 上でコミットとして閲覧でき、ニュースファイルに記載されていることがわかります。

私は以前から tz リポジトリを眺めており、常に興味深い情報を得ています。たとえば第二次世界大戦中のイギリスでは「ダブルサマータイム」を採用し、夏は2時間、冬は1時間時計を進めました。このような世界各地での時刻変更史を詳細に記録したコメントがデータベース全体の大部分を占めています。

しかし、この重要なリソース（多くのソフトウェアが直接・間接的に利用している）には、驚くほどユーモラスな要素も散りばめられています。北米ファイルだけでも次のようなエントリーがあります。

  • 1947 年、カナダの知識人ロバートソン・デイビスが日光節約時間（DST）に対して熱烈に反発した言葉
    「私は時間の測り方自体にはあまりこだわらない。ただし、何らかの合意があることは望む。『日光を節約』と告げられるのは、私の理性からすると実際に何もしていないという意味であり、私はそれに反対する。太陽が昇った後にベッドにいることで貴重なものを浪費しているとの示唆にも抗議する。月光の愛好家として、時間を楽しむことを制限しようとする者たちの強引さには嫌悪感を抱く。日光節約計画の裏に潜むピュリタニズムの骨折り青指の手が、人々を早く寝かせ、早く起こすことで彼ら自身にも健康・富・知恵をもたらそうとしていると感じる。」
    – ロバートソン・デイビス、『サミュエル・マーチベンクスの日記』

  • 1950 年代にナッシュビルで「対立する顔」を持つ公共時計の話――保守派用と自由主義者用の2種類が並んでいた。

  • 1883 年、ニューヨーク市で起きた「二重正午」の物語。標準時区が採択され、従来の「地方時間」が永遠に廃止された瞬間です。

  • 北極圏北部の小さなコミュニティ・レジリュート湾で、タイムゾーンの適切な年代順序を特定するという探偵物語。

時刻が狂気と化すこともありますが、それらを記録しているデータベースは人間味あふれる魅力に満ちています。

同じ日のほかのニュース

一覧に戻る →

2026/03/08 5:43

CAS番号（化学物質登録番号）

## Japanese Translation: CasNumは、コンパスと定規を用いた幾何学的構成により任意精度算術を実装するPythonライブラリです。数値は平面上の点としてエンコードされ、加算・乗算・除算・論理ゲートなどの演算は、線/点、円、直線と円の交点などの5つの基本的な幾何学プリミティブから構築されます。最適化には、2倍による特殊ケース乗算や剰余計算で最高位ビット（2のべき乗）を除去する手法が含まれています。 このライブラリはGame BoyエミュレータのALUに組み込むことを想定しています。CasNumを統合するには、PyBoy の `opcodes_gen.py` を編集するだけで、他のエミュレータコードは変更されません。使用例としては、単純なRSA実装（`python3 -m examples.rsa`）や、幾何学ベースの算術のみで動作させるポケットモンスター 赤版（`python3 -m examples.basic`）があります。初回起動に約15分かかりますが、その後はPython の `lru_cache` によりほぼ 0.5–1 FPS で再起動できます。 ビュアースクリプト (`casnum/cas/viewer.py`) は幾何学的構成を可視化し自動ズームします。RSA例では手動ズームが必要になる場合があります。依存関係は、sympy（コア）、可視化用のオプション pyglet、テスト用 pytest‑lazy‑fixtures、RSA 用 pycryptodome、および任意で Euclid Postulate V です。インストールは `git clone --recursive` の後に `pip install -r requirements.txt` を実行します。使用している ROM（`2048.gb`）は zlib ライセンス、CasNum コアコードは MIT ライセンス、PyBoy は LGPL v3.0 でライセンスされており、このプロジェクトはオープンソースや教育プロジェクトに適しています。

2026/03/08 6:56

3T ブラインドスポット：米国の非営利団体

## Japanese Translation: **概要** 米国の非営利セクターは年間 **3兆ドル** を管理しており、これはイギリスのGDPを上回る金額ですが、そのうち実際にプログラム費用に充てられるのは **約36％（1,800億ドル）** に過ぎません。残りはオーバーヘッド、スタッフ給与、資金調達に使われています。登録済み非営利団体は **180万人以上** であり、その多くは収益が5万ドル未満の場合 IRS Form 990 の提出義務から免除されているため、セクター全体の大部分が公衆の監視から隠れています。 寄付者の信頼感は低下しています。**米国の寄付者の32％が5年以上前よりも慈善団体に不信感を抱いています**（BBB Wise Giving Alliance）、世界的にも三分の一が非営利団体への信頼を失っています（Gallup）。財務的負担は顕著で、**調査対象の非営利団体の36％が2024年末に営業赤字を報告し、10年間で最高水準となりました**。また **41％しか全職員に生活賃金を支払えません**。資金提供者は通常オーバーヘッドを約15 % に抑えるよう指示しますが、多くの非営利団体は管理費に **31 % 近くを使っており、過小報告やコーナーカットが頻発する** ― これは「非営利組織の飢餓サイクル」と呼ばれる現象です。 企業会計との大きな違いは顕著です。IRS Form 990 は年間一度提出され、公開までに **12–18か月** を要し、監査済み財務諸表や詳細なプログラム内訳が欠如しています。一方で公的企業は **10-K（年次）、10-Q（四半期）、8-K（重要事象）** を提出し、60日以内に監査済みの声明を求められます。このコンプライアンス中心の枠組みが可視性の問題を生み出し、寄付者の信頼を侵食しています。 国際的には、英国で実施された研究で **ウガンダの井戸の45％が非営利団体によって資金提供されましたが、機能していませんでした**。これにより 2億1,500万〜3億6,000万ドル相当のリソースが無駄になっています—非効率性の重大さを示しています。既存技術（カメラ・センサー・衛星画像）はリアルタイムで成果を追跡できる可能性がありますが、現在の報告規則ではそのような機能は義務付けられていません。 非営利セクターの将来は、コンプライアンス重視から真の透明性と説明責任への転換にかかっています。この変革なしには、非営利団体は営業赤字と寄付者の懐疑心を続けるでしょう。変革が実現すれば、信頼を回復し持続可能な資金調達を確保できる可能性があります。

2026/03/06 16:17

既存のブリックからLEGO NXTファームウェアをダンプする（2025）

## Japanese Translation: > 著者はPybricksプロジェクトで作業している際、オリジナルのファームウェアバージョン 1.01を動作させていた中古Lego NXTを入手し、このファームウェアの保存コピーが存在しないこと（利用可能なのは新しい 1.03のみ）に気づきました。 > > NXTのAT91SAM7S256 MCU上では、SAM‑BA PEEK/POKE を呼び出すことはできますが、それを行うとファームウェアを書き換えてしまい、古いMCUにはモダンなデバッグインターフェースが欠けているためJTAGも実用的ではありません。ロボットのプログラムは制限付きメモリ内で動作するバイトコードVMで走るので、著者は低レベル機能に焦点を当てました。 > > PyUSB を介して USB 「Read IO Map」コマンドを送信し、`0x100d3d`（フラッシュの約 3 KiB）に位置するVMの書き込み可能な関数ポインタ `pRCHandler` を読み取りました。32 KiB の書き込み可能 MemoryPool は NOP とカスタム ARM コードで埋めることができ、`pRCHandler` をこのプール内のアドレスにリダイレクトすることで任意の直接コマンドをそのコードとして実行させることができます。 > > 著者は、受信パケットから4バイトのアドレスを読み取り、そのアドレス上のワードを返す組み込みアセンブリを挿入し、元のハンドラを置き換えました。この乗っ取られたハンドラを利用して、USB経由で「direct」コマンドをバイト単位で送信し、フラッシュ領域全体（`0x00100000–0x00200000`）を読み取り、完全なファームウェアとユーザーデータを `nxtpwn-dump.bin` にダンプしました。 > > この脆弱性は、ストックファームウェアを実行している任意のNXTで機能し、未改変デバイス上でもベアメタルコードが動作できることを示しています。これにより、保存ツールや自己複製型マルウェアなどの可能性が開かれ、NXTファームウェアの整合性チェックにおける脆弱性も浮き彫りになっています。