日期与时区差
两日期差几天几年零几月一眼算清（闰年、DST 都不会错），墙钟时间跨时区换算直接出结果。
>_ 使用指南 · GUIDE
两个日期之间的差距一次算清：相差多少天、以及几年零几月零几天的精确拆分（「合同期 1 年 6 个月零 3 天」这种表述直接可用）。闰年、大小月自动处理，不会差一天。
另附墙钟时间跨时区换算：同一个时刻在东京、纽约、伦敦各是几点——不是简单的减 8 加 8，含夏令时（DST）的正确换算。典型场景：合同/签证期限计算、项目排期倒计时、跨国会议时间确认。本地计算，零网络。
>_ 常见问题 · FAQ
Q1 · 为什么「相差天数」和「几年几个月」要分开看？
两种口径回答不同的问题：总天数回答「一共多少天」（如利息按天算），年月拆分回答「日历上的期限」（如合同写「一年」是到次年同日，而非固定 365 天）。闰年时同一年期可能是 365 或 366 天——所以两套口径并存，按用途选用。本工具同时给出，不用自己换算。
Q2 · 跨时区换算为什么容易错？夏令时是什么？
容易错在两个坑：① 各时区偏移不同（东京 +9、纽约 −5）；② 夏令时让偏移随季节变化（纽约冬天 UTC−5、夏天 UTC−4），美国欧洲的切换日期还不一样。所以「纽约比北京晚 13 小时」这类说法只在半年内成立。正确做法是按 IANA 时区规则换算——本工具已内置，直接选城市。
Q3 · 2024 年 2 月 29 日这种日期能算吗？
能。闰日按真实日历处理：2 月 28 日到 3 月 1 日在闰年是 2 天、平年是 1 天。涉及「满一年」的口径也按日历走（2 月 29 日的周年在平年落到 2 月 28 日或 3 月 1 日，取决于所采用的惯例，常见法律口径为次年 2 月 28 日）。关键日期建议以合同文本约定为准，工具计算用于核对。
Q4 · 为什么两个日期差一天，程序算出来却差 8 小时或 23 小时？
时区混算的经典 bug：把「日期」解析成「当日 00:00 的本地时间」再相减，遇到跨时区或 DST 切换日就不是整 24 小时。纯日期差应按日历日计算（忽略时刻），时刻计算才引入时区——本工具两条路径分开处理，也提醒你在代码里别混用 Date 的两种语义。
Q5 · 跨国会议时间怎么安排最合理？
先找「各参与方都是工作时间段」的交集窗口（常用约定：每人不早于 8 点不晚于 18 点）。北京与纽约的实际重合窗口很窄（北京早上 = 纽约傍晚，还随 DST 漂移），固定每周例会时要意识到夏令时切换后时间会偏移，建议用日历工具的时区功能建立事件，本工具用于快速核对换算结果。