日期不同，未必是时间错了
2026年10月23日北京时间00:30，对应UTC的10月22日16:30。把两条字符串只截前十位比较，会误判为不同事件；删除时区后重新解析，还可能真的改变时刻。
让Claude整理跨地区日程时，应同时保留原始时间文字、偏移和约定展示时区。本篇只做固定偏移的离线转换，不创建真实日历、不发送邀请。
先分清时刻和日历日期
某活动“10月23日全天”不是00:00的同义词；生日、账期日期也不一定对应一个全球统一瞬间。只有材料明确了时分秒与偏移，才适合按时刻转换。
虚构A为2026-10-23T00:30:00+08:00，B为2026-10-22T16:30:00Z，人工预期是同一瞬间。RFC 3339描述带UTC关系的时间戳，可帮助避免没有偏移的含糊表示。
一个故意只支持窄范围的函数
文末toUtcInstant接受1000—9999年、秒精度和Z或+08:00两种表示。先校验日期确实存在，再减去给定8小时，输出UTC。没有时区、24点和不存在的2月29日都拒绝。
它不是完整RFC 3339或ISO 8601解析器：不支持其他偏移、闰秒、小数秒、区域夏令时与重复日程。拒绝超出子集的输入，是为了不把默认猜测伪装成已识别。
运行并核对跨日结果
保存为explicit-zone-time.mjs，用Node.js 24 LTS运行node explicit-zone-time.mjs --demo。输出a、b都应为2026-10-22T16:30:00.000Z；这表示同一时刻，不是说活动在北京也变成22日。
展示时再明确指定Asia/Shanghai等目标地区，避免依赖运行电脑默认时区。原始材料与标准化UTC都应保留，方便用户发现模型是否读错了日期或偏移。
遇到“明早”“下周五”怎么办
先询问参照日期、所在地和预期时间。没有这些信息时保留待确认，不能用服务器今天或模型当前日期补齐。材料中的偏移也不应自动推广到某个地区全年规则。
请Claude输出原文、已确认字段、标准化时间、未知条件四列；任何尚未确认的字段都不进入自动预约。解析成功只说明这个输入在函数范围内，不构成发送通知的授权。
测试与使用边界
本地实际测试了两个等价时刻、有效闰日、无时区、非法日期及尾随换行拒绝。没有连接Claude、日历、真实预约系统，也没有测试夏令时地区。
如果业务必须处理地区时区，应使用受维护的时区实现并测试转换边界，不能靠本例固定减8小时处理所有国家。
参考资料与核验范围
资料核对日期：2026年10月21日。以下为官方原始资料；产品入口和可用范围仍以当前账户为准。
1. [官方资料1](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)
2. [官方资料2](https://www.rfc-editor.org/rfc/rfc3339)