时区转换器

本工具侧重「同一时刻在不同时区下的本地表示对比」，适合跨时区协作、会议安排、国际化展示；Unix 时间戳转换工具侧重「绝对时间与人类可读时间的双向换算」，适合日志分析、API 调试、缓存过期计算。两者互补：时间戳是时区无关的绝对值，时区转换则是把绝对值映射到不同地区的本地时间。本工具在每张时区卡片中同时展示 Unix 时间戳，可一键复制后前往时间戳工具进一步处理。

IANA 时区数据库（又称 tz database、tzdata）是由互联网号码分配局（IANA）维护的全球时区标准，每个时区以「区域/位置」形式命名，如 Asia/Shanghai、America/New_York、Europe/London。命名优先选择能代表该时区规则的最大人口城市，而非当前政治边界。例如中国大陆统一使用 Asia/Shanghai（而非 Beijing），因为历史时区规则以上海记录为准。本工具的所有时区均来自 IANA 数据库，与 Linux、macOS、Java、Python、JavaScript 等主流技术栈一致。

UTC（协调世界时，Coordinated Universal Time）是基于原子钟的国际时间标准，用闰秒修正地球自转减速，是现代所有时间同步的基准。GMT（格林尼治标准时间，Greenwich Mean Time）是历史概念，指本初子午线处的平均太阳时，现已基本被 UTC 取代。日常使用中两者数值相同（UTC+0 ≈ GMT），但技术上 UTC 更精确。IANA 数据库中伦敦的「标准时间」（非夏令时）即 UTC+0。

夏令时（Daylight Saving Time，DST）是在夏季将时钟拨快一小时，以充分利用日光、节约能源的做法。通常在春季「拨快」、秋季「拨回」。例如 America/New_York 标准时间为 UTC-5（东部标准时间 EST），夏令时为 UTC-4（东部夏令时 EDT）。Europe/London 标准为 UTC+0（GMT），夏令时为 UTC+1（BST）。中国大陆、日本、印度等不使用夏令时。本工具会自动识别并标注「夏令时」徽章，偏移也会随之调整。

这正是夏令时导致的。例如 America/New_York 在 3 月第二个周日到 11 月第一个周日为 UTC-4（夏令时），其余时间为 UTC-5（标准时间）。本工具根据输入时间所处的具体日期计算偏移，因此同一城市在不同日期会显示不同的 UTC 偏移。注意南半球夏令时方向相反（如 Australia/Sydney 在北半球冬季为夏令时）。

ISO 8601 是国际标准的日期时间表示格式，基本形式为 YYYY-MM-DDTHH:mm:ss。带偏移的完整形式在末尾附加 ±HH:mm，如 2026-07-08T14:30:00+08:00 表示东八区下午两点三十。UTC 时间可用 Z 后缀表示，如 2026-07-08T06:30:00Z。带偏移的 ISO 8601 是 JSON、REST API、数据库 timestamp 字段的首选格式，因为它能无损还原为绝对时间。本工具每张时区卡片均输出带偏移的 ISO 8601。

源时区是「你输入的时间所采用的时区」。例如你有一张北京时间的会议通知，想把会议时间换算成纽约、伦敦时间，则源时区选 Asia/Shanghai，目标时区添加 America/New_York、Europe/London。工具默认用浏览器系统时区作为源时区，可手动切换。目标时区可任意添加、删除，默认展示 UTC、北京、纽约、伦敦、东京五个常用时区。

现代浏览器内置 IANA 时区数据库（随操作系统或浏览器更新），通过 Intl.DateTimeFormat 的 timeZone 选项即可使用，无需联网。本工具所有时区计算均在浏览器本地完成，不上传任何数据。时区数据库会随操作系统更新（如 Windows Update、macOS 系统更新），各国夏令时规则变更时会同步。极少数旧浏览器可能不支持完整 IANA 列表，本工具提供常用时区预设降级方案。

Unix 时间戳是「自 1970-01-01 00:00:00 UTC 起经过的秒数」，它是时区无关的绝对时间。同一时刻，全球所有时区的 Unix 时间戳相同。时区转换的本质是：把一个绝对时间戳，格式化为不同地区的本地时间字符串。因此本工具中所有时区卡片的 Unix 时间戳值完全一致，区别仅在本地表示。这也是为什么后端存储、API 通信推荐用 Unix 时间戳或 UTC ISO 8601，而前端展示时再按用户时区格式化。

多数时区以整小时偏移（如 UTC+8、UTC-5），但部分时区使用半小时或四十五分钟偏移。例如 Asia/Kolkata（印度）为 UTC+5:30，Asia/Tokyo 为 UTC+9，Asia/Kathmandu（尼泊尔）为 UTC+5:45，Australia/Adelaide 为 UTC+9:30。这些奇数偏移多源于历史与地理因素（如印度按其中心经度定位）。本工具的偏移标签会精确显示到分钟，如 UTC+5:30。

① 始终以 UTC 或 Unix 时间戳作为「真相源」记录会议时间，避免歧义；② 邀请函中同时标注参与者所在时区的本地时间，本工具可一次生成多个时区对照；③ 注意夏令时切换日（每年 3 月、11 月附近），切换当周可能造成会议时间错位；④ 使用带偏移的 ISO 8601（如 2026-07-08T14:00:00+08:00）在日历软件中最可靠；⑤ 跨半球协作时注意南半球夏令时与北半球相反。

常见坑：① 后端存储本地时间而非 UTC，导致跨时区错乱；② 前端 new Date('2026-07-08') 被当作 UTC 午夜，在负偏移时区显示为前一天；③ 假设偏移恒定忽略夏令时；④ 用字符串拼接而非 Intl.DateTimeFormat 格式化。最佳实践：① 后端与数据库统一存 UTC；② API 传输用 ISO 8601 带偏移或 Unix 时间戳；③ 前端用 Intl.DateTimeFormat 按用户时区格式化；④ 涉及定时任务时用 Asia/Shanghai 等 IANA 时区名而非 +08:00 偏移（偏移不随夏令时变化，时区名会）；⑤ 测试覆盖夏令时切换边界。

完全安全。本工具所有时区计算、格式化、夏令时识别均在浏览器本地完成，不会上传任何时间数据到服务器。没有后端、没有数据库、没有统计脚本。你输入的时间仅在你的设备内处理，适合处理敏感的会议安排、日志时间等场景。