像“美东时间晚上8点”这样的描述很容易引起歧义。发起者往往指的是纽约当下的本地时间，而纽约夏令时与冬令时的 UTC 偏移量并不相同。通过指定诸如 America/New_York 这样的标准 IANA 时区与日期，工具就能精确应用对应的时差。
来源时区与查看者时区的不同职责
来源时区决定工具如何解读你输入的日期与时间；查看者时区则仅决定预览区域如何呈现该时刻。更改预览并不会移动事件的真实时间点。
在本工具中，切换来源时区同样会锁定现有时间点不变，输入框会自动换算为新时区对应的年月日时分秒。如果你想更改聚会时间，请在选定时区后再编辑日期与时间。
具体换算实例
在上海 2026 年 10 月 10 日 20:30，对应 UTC 时间 12:30，在纽约则是上午 08:30，东京显示为 21:30。这四种视角全部对应 Unix 秒数 1791635400，采用同一段 Discord 代码。
当活动临近日落或午夜时，不同时区的读者可能会看到不同的日历日期，这是完全正常的。当日期重要时，请选用完整日期格式 F。
夏令时可能会导致时间缺失或重复
以纽约为例，2026 年 3 月 8 日时钟直接从 01:59 跳至 03:00。当地不存在 02:30 这个时刻。生成器会明确提醒你调整，而不是暗中移动活动时间。
而在 2026 年 11 月 1 日，纽约的 01:30 会出现两次（第一次为 UTC−04:00，第二次为 UTC−05:00），两者相差整整 1 小时。请在工具中指定是第 1 次还是第 2 次发生。
并非所有时区都按照整小时调整，也并非所有国家都采用夏令时。工具依据浏览器提供的权威 IANA 数据库进行换算。请保持浏览器更新以获得最新时区规则。
“明天”按钮遵循本地日历
点击“明天”快捷按钮，会跳转到当前来源时区的下一个日历日，并保持相同的本地时钟数字。若跨越夏令时切换点，实际间隔可能是 23 或 25 小时。
而“+15分钟”与“+1小时”快捷按钮则是从当前绝对时刻往后推算，适合即将开始的临时集会。
发布前的最终核对
发布前请核实来源城市、日期，并在第二个时区下进行预览。建议复制包含 F 和 R 的公告。若收到别人发来的代码，请使用 转换器 查看其真实的 UTC 数值。