预约写着下午3点，到底是哪个地区的3点？

加时间选择器之前，先确定约定的是谁的时间

假设有一场60分钟的线上工作坊，参加者来自不同地区。收到的需求是“让主办方选择预约日期和时间”。看起来加个选择器就够了，但如果主办方的下午3点被解释成每个参加者设备上的下午3点，大家就会在不同时刻进入。先确认这是不是一场要求所有人同时参加的活动。

这个案例中，主办方明确选择活动时区，参加者则用自己选择的时区查看同一个时刻。重复课程、全天事件和线下场地预约不在本次范围内。“每周当地下午3点”或门店营业时间可能需要另一套规则，不能直接照搬。

在需求文档里先写清时间由谁确定，以及确认后维持什么约定。本例选择固定已确认的时刻，即使时区规则更新，也不自动移动活动。主办方想改时间，要单独确认改期。先确定这一点，才能避免不同页面实现不同的“预约时间”。

只保存日期和时间，这个方案要补一项

最初可能会想，先保存选择器的值，读取时再按地区转换。但MDN对日期时间输入的说明揭示了缺项：datetime-local本身不包含时区。界面是韩语也不能代表韩国时间，使用韩语的人完全可能身在美国。

时区名称指向一个地区的时钟规则。例如Asia/Seoul表示首尔的规则；UTC+09:00表示某个时刻比UTC快9小时。名称与偏移值的作用不同。处理未来日期时，只记录今天的偏移，可能无法正确处理季节或规则变化。

因此把输入说明改为日期、时间、活动时区三项。从系统支持的时区列表中选择，浏览器检测到的地区只作为建议，主办方仍需确认。设计说明还要写清：切换界面语言不能改变已选时区，并把这个条件交给QA核对。

先检查这个当地时间能否唯一确定

日期格式正确，不代表可以直接确认预约。有些地区会调整时钟，导致某个当地时间根本不存在，或在同一天出现两次。服务器要按所选日期和时区规则计算实际候选时刻，不能只凭浏览器输入校验通过就接受预约。

没有候选时刻时，提示“所选地区不存在这个时间，请选择其他时间”。不要偷偷调整到最近的时刻。有两个候选时刻时，要区分第一次出现的1点30分，以及时钟回拨后再次出现的1点30分。把UTC偏移和参加者时间一起显示，让主办方明确选择。

确定唯一候选后，再进入最终确认。提交时服务器重新校验输入和规则，并比较预览版本。如果预览后输入或换算结果变了，就显示新结果并再次确认。不能拿用户看过的旧预览，授权保存另一个时刻。

重新确认条件要写得明确：提交确认时，只要原始输入、所选重复时刻或时区规则库版本与预览不一致，就让旧预览失效。即使只改变了规则库版本，换算后的UTC时刻完全相同，也要重新展示预览并再次确认。

用具体数值检查遗漏的条件

只看一个正常的韩国时间示例，很多设计都会显得没问题。所以要分别检查正常时间、不存在的时间和重复时间。本文用Python zoneinfo把当地时间转成UTC，再转回原地区进行核对；如果两个候选指向同一UTC时刻，就去掉重复项。

纽约的2026年11月1日01:30有两个候选：05:30Z和06:30Z。反过来，3月8日02:30没有任何候选能够转回原始当地输入。实现验收时也要记录所用时区规则库的版本。库自动修正出来的值，不能被当成“原时间有效”的证据。

下面的情境选择展示的是固定设计示例，不会创建预约或发送通知。交给开发时，应把这些值作为服务器响应的对照样本。以后增加支持地区，也要增加对应地区的边界日期，而不是只重复检查正常日期。

把确认记录与当前显示分开

只写“保存UTC”还不够，后续人员无法知道为什么选了这个时刻。需要同时保留主办方原始当地日期与时间、活动时区、重复时刻中所选的偏移、确定的时刻以及当时规则版本。存储说明要区分原始输入与当前显示，不能相互覆盖。

参加者页面把活动基准和我的基准放在一起，例如“10月15日15:00·首尔／我的时间：10月14日23:00·洛杉矶”。不要省略日期，也要允许手动切换显示时区，避免设备设置错误时用户无法核对。

本例中的60分钟表示实际经过的时长。在已确认开始时刻上加60分钟得到结束时刻，然后分别转换显示。遇到时钟回拨，不能直接拿当地钟面数字相减计算时长。如果开始和结束跨日期，就分别显示两边的日期。

让AI先找遗漏，再核对它给出的换算

只让AI“写一份时区预约需求”，答案可能停在“用UTC存储”。应该先给出一次性线上活动的范围、确认后固定时刻的决定，以及画面必须显示的两个日期。下面是可用于工作的提问示例，并非实际执行的对话。

如果答案只写“转换成美国时间”，就缺少具体地区。要指定纽约与洛杉矶，并补问重复时刻如何选择。可以这样追问：“请写出区分两个01:30的选项文案，以及用户未选择时服务器必须拒绝的条件。”问题越具体，越容易核对答案遗漏了什么。

采纳标准不是文字是否流畅，而是正常、缺口与重复这三组样本是否一致，是否拒绝不存在的时刻，以及是否遵守确认后的约定。AI给出的数值要与时区库结果对照后再放进文档，未经验证的答案不能直接成为设计依据。

提问示例：我们在设计面向跨地区参加者的一次性60分钟线上活动。主办方确认活动时区，确认后固定UTC时刻。请检查输入到最终确认之间缺少的条件，分别处理不存在的时间、重复时间、设备时区变化及预览后规则变化。给出画面提示和服务器拒绝条件，不讨论重复日程。

改期与发送通知，要分开处理

主办方修改已经确认的时间，改变的是约定本身。先显示新的预览，获得明确确认后再更新日程版本。保留旧值、新值和变更理由，方便运营核对，再向受影响的参加者发送指向最新日程的通知。

通知发送失败，不应把已经提交的新日程回滚。预约详情仍显示新版本，只重试失败的发送。按参加者与日程版本记录发送结果，减少重复通知。发送成功也不等于用户已经阅读或同意改期，这几个状态不能混在一起。

规则库更新后要检查影响。本例固定已确认时刻，因此可能改变的是当地显示。找出受影响的日程及参加者并说明变化。如果主办方希望维持原来的当地钟面时间，就走明确的改期流程。自动更新不能代替主办方确认。

给QA具体数值，不要只说选择器能用

如果只选择一个日期再点保存，就很难发现这些问题。把输入、所选时区、预期UTC时刻和显示日期连成一条测试。错误输入不仅要显示提示，还要确认没有写入预约。前端虽然阻止操作，但直接请求能绕过服务器判定，问题依然存在。

下表是实现后要验证的条件。本文通过计算确认了正常、缺口与重复时间的数值；保存预约、版本冲突和通知失败仍需要在真实服务中联调。设计审查通过与服务验收通过，要分别记录，不能用同一个完成标记代替。

复用前，先改写你自己的时间约定

下面的交接说明可以带走，但不要从替换时区名称开始。先确定你的服务承诺什么：线上活动的共同时间点，还是与实体场所相关的当地钟面时间。若是后者，就要重新决定规则变化时如何维持预约，不能照搬本例。

策划确认范围和改期政策，开发补充支持时区、规则库更新方式和服务器判定结果，设计连接双日期显示与重复时刻选择，QA拿验收表对照真实响应。运营交接中还要明确谁负责规则更新及失败通知，不能只交一张页面。

首次上线时，如果边界验证失败，就先阻止新的预约确认并修复原因。不要为了让数据看起来一致而批量覆盖已有预约的确定时刻。修复后重新验证新输入，并把可能受影响的已有日程单独列出来检查，这才是下一步。

一次性线上工作坊——开发与QA交接说明
适用范围：面向跨地区参加者的60分钟线上活动。排除重复日程、全天事件和线下场地预约。
决策：确认前以主办方输入的当地日期、时间及活动时区确定含义；确认后以保存的UTC时刻作为约定。
基准示例：2026-10-15 15:00，Asia/Seoul，UTC+09:00 → 2026-10-15T06:00:00Z；结束为07:00Z。纽约开始时间为10月15日02:00，洛杉矶为10月14日23:00。
输入：分别显示日期、时间和活动时区。浏览器时区只作为建议，须由主办方确认。界面语言不改变时间。
确认前：服务器检查时区是否受支持，并计算候选时刻。0个时说明当地时间不存在；2个时显示各自UTC偏移及第一次/第二次出现的说明，让用户明确选择。禁止静默修正或默认选择第一次。
最终确认：同时显示活动日期、时间、地区、UTC偏移，我的时区下的日期与时间，以及60分钟时长。服务器重验输入及规则并比较预览版本；结果变了就重新展示并再次确认。
记录：原始当地日期与时间、活动时区、所选UTC偏移、已确认UTC起止时刻、确认时间、时区规则库版本、日程版本和变更理由。显示值与原始输入分开。
确认后：设备时区改变仅影响显示。时区规则更新即使改变当地显示，也不得自动移动已确认UTC时刻。变更说明与当前日程一起展示。
改期：主办方另行预览并确认变更，再更新日程版本。保留旧值和理由。通知链接指向新版本；发送失败进入待重发队列，不回滚已经确认的日程。
分工：策划确定时间约定与改期范围；开发负责服务器判定、版本冲突与换算；设计负责双日期及错误提示；运营核对通知对象与失败发送；QA验证边界值。
验收：韩国/纽约/洛杉矶显示、无效或未选时区、夏令时缺口、重复时刻、明确选择后的重验、设备变化、语言变化、过期预览、规则更新及通知失败。
上线前：确定支持时区清单、规则库更新负责人及通知重发责任人。边界验证失败时阻止新的预约确认，修复原因，同时保留已有预约的确定时刻。
验证范围：文中的数值用Python zoneinfo做了往返换算；没有实现或联调真实预约与通知服务。
重新确认条件要写得明确：提交确认时，只要原始输入、所选重复时刻或时区规则库版本与预览不一致，就让旧预览失效。即使只改变了规则库版本，换算后的UTC时刻完全相同，也要重新展示预览并再次确认。

来源与示例条件

本文使用虚构的60分钟线上工作坊案例。公开资料支持时间表示的基础事实，预约及变更政策为本例自行设计。数值已用Python zoneinfo做往返换算，并非真实预约服务联调结果。AI提问均为未执行示例。英文与中文是同一韩文案例的本地化版本。

MDN — datetime-local input

W3C Group Draft Note — Working with Time Zones

RFC 3339 — Date and Time on the Internet