MySQL 时间转换遇到夏令时，重复时刻怎么处理

纽约当地的 2025-11-02 01:30:00 不是唯一时刻。夏令时结束，时钟回拨，同样的墙上时间出现两遍：一次对应 UTC 05:30，另一次对应 UTC 06:30。如果只存本地 DATETIME 和城市名称，后面再聪明的转换函数也补不回丢掉的那一小时身份。

时间转换出错，经常不是函数算错，而是输入一开始就不够。已经发生的事件需要确定的时间线位置；未来“当地每天上午九点”的计划则需要时区规则。两种数据不能只因都长得像日期字符串，就用同一列承载。

先确认这台 MySQL 能识别命名时区

本文 SQL 按 MySQL 8.4 编写，使用已经加载 IANA 时区规则的实例。先运行：

SELECT
    CONVERT_TZ('2025-11-02 05:30:00', '+00:00', 'America/New_York') AS first_local,
    CONVERT_TZ('2025-11-02 06:30:00', '+00:00', 'America/New_York') AS second_local;

两列都应得到当地 01:30。如果返回 NULL，应先检查时区名称和实例的时区规则数据，不能把 NULL 当成合法转换继续存入业务表。固定偏移 -05:00 不能替代纽约的全年规则，夏季与冬季偏移不同。

这条查询从两个确定的 UTC 时刻出发，所以结果没有歧义。反过来，只有当地 01:30 再加 America/New_York，仍不足以指定它属于回拨前还是回拨后。不应依赖某一版数据库碰巧选中的那一份作为业务协议。

已发生事件，保存确定的 UTC 与原始输入证据

这个表用 DATETIME(6) 存 UTC，列名明确带 _utc。它不会因 MySQL 会话时区改变而自动转换，写入方必须遵守 UTC 契约。同时保留原始本地值、时区名和当时偏移，方便核对输入。

CREATE TABLE zoned_event_sample (
    id BIGINT NOT NULL,
    occurred_at_utc DATETIME(6) NOT NULL,
    source_local DATETIME(6) NOT NULL,
    source_zone VARCHAR(64) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
    source_offset_minutes SMALLINT NOT NULL,
    event_name VARCHAR(100) NOT NULL,
    PRIMARY KEY (id),
    KEY idx_event_time (occurred_at_utc, id)
) ENGINE=InnoDB;

INSERT INTO zoned_event_sample
    (id, occurred_at_utc, source_local, source_zone,
     source_offset_minutes, event_name)
VALUES
    (1, '2025-11-02 05:30:00', '2025-11-02 01:30:00',
        'America/New_York', -240, '回拨前事件'),
    (2, '2025-11-02 06:30:00', '2025-11-02 01:30:00',
        'America/New_York', -300, '回拨后事件');

SELECT id, occurred_at_utc, source_local, source_offset_minutes,
       CONVERT_TZ(occurred_at_utc, '+00:00', source_zone) AS rebuilt_local,
       TIMESTAMPDIFF(MINUTE, occurred_at_utc,
           CONVERT_TZ(occurred_at_utc, '+00:00', source_zone)) AS rule_offset
FROM zoned_event_sample
ORDER BY occurred_at_utc, id;

两条事件在当地显示相同，但 UTC 顺序相差一小时，偏移分别是 -240 与 -300 分钟。不要对 (source_zone, source_local) 建唯一约束，它会拒绝本来可以同时存在的事件；也不要拿这两个字段充当去重键。

MySQL 的 TIMESTAMP 会按会话时区在写入、读取时转换，DATETIME 则保存给定的日期时间值。这里选后者是为了让实验的 UTC 语义可见，并不表示 TIMESTAMP 不能用于事件。若采用 TIMESTAMP，连接初始化、驱动映射和查询条件都必须固定到相同时间线，不能把转换责任留给管理工具默认设置。

输入只有本地时间，必须先识别歧义

Python 3.12 的 zoneinfo 可以对候选时刻做往返验证。以下程序不会替用户擅自选第一份；它返回零个、一个或两个确定的 UTC 候选，让接口决定拒绝还是要求补充偏移。

保存为 local_candidates.py。运行环境需要系统 IANA 时区数据，或安装相应的 tzdata 数据包。

from datetime import datetime, timezone
from zoneinfo import ZoneInfo


def utc_candidates(local_text, zone_name):
    local = datetime.fromisoformat(local_text)
    if local.tzinfo is not None:
        raise ValueError("this entry accepts a local time without offset")
    zone = ZoneInfo(zone_name)
    candidates = {}
    for fold in (0, 1):
        attached = local.replace(tzinfo=zone, fold=fold)
        utc = attached.astimezone(timezone.utc)
        restored = utc.astimezone(zone)
        if restored.replace(tzinfo=None) == local:
            candidates[utc] = restored
    return sorted(candidates)


def main():
    ambiguous = utc_candidates("2025-11-02T01:30:00", "America/New_York")
    missing = utc_candidates("2025-03-09T02:30:00", "America/New_York")
    normal = utc_candidates("2025-11-02T04:30:00", "America/New_York")
    assert [item.isoformat() for item in ambiguous] == [
        "2025-11-02T05:30:00+00:00",
        "2025-11-02T06:30:00+00:00",
    ]
    assert missing == []
    assert len(normal) == 1
    print("ambiguous:", [item.isoformat() for item in ambiguous])
    print("missing:", missing)
    print("normal:", normal[0].isoformat())


if __name__ == "__main__":
    main()

fold=0 与 fold=1 表示回拨重叠中的两份候选。对普通时刻，它们最终得到同一份 UTC，字典会去重；对春季跳时中不存在的当地 02:30，往返后恢复不了原值，因此两份候选都被丢弃。

直接给一个无时区 datetime 调用 replace(tzinfo=zone)，只是附加解释条件，不保证这个墙上时间在当地历史中真的存在。创建对象没有报错，不等于输入有效。往返检查正是为了把“能构造一个对象”与“真实时间线上有这个当地时刻”分开。

接口若收到两份候选，应要求明确偏移或具体发生时刻。若收到零份，应拒绝这条不存在的输入，或者按事先公开的业务规则改期。悄悄把 02:30 推到 03:30，会让用户认为原时间已经被接受，实际安排却不同。

Python 函数返回的是带 UTC 时区信息的对象。写入本文的 UTC DATETIME 列前，可在驱动约定的位置移除时区标记，但只应在已经完成 UTC 转换之后执行。不能先对原始当地值去掉时区，再把结果当作 UTC 写入；日期字符串仍然合法，记录却会整体偏移数小时。这种错误通常不会触发数据库异常。

若上游已带 -04:00 或 -05:00，可以先确定 UTC，再把它转换回所声明的命名时区，检查当地值与偏移是否一致。带偏移和带城市名称并不必然一致，二者都传时反而应该做一致性校验，不能任选一项覆盖另一项。

当地一天，可能覆盖 25 个小时

对纽约当地 11 月 2 日做日报，不能拿 UTC 起点简单加 24 小时。应该分别把当地当天零点和下一天零点转换成 UTC，再用半开区间检索。

SET @day_start_utc = CONVERT_TZ(
    '2025-11-02 00:00:00', 'America/New_York', '+00:00'
);
SET @next_day_start_utc = CONVERT_TZ(
    '2025-11-03 00:00:00', 'America/New_York', '+00:00'
);

SELECT @day_start_utc, @next_day_start_utc,
       TIMESTAMPDIFF(HOUR, @day_start_utc, @next_day_start_utc) AS hours;

SELECT id, occurred_at_utc, event_name
FROM zoned_event_sample
WHERE occurred_at_utc >= @day_start_utc
  AND occurred_at_utc < @next_day_start_utc
ORDER BY occurred_at_utc, id;

起点应是 UTC 04:00，终点是次日 UTC 05:00，区间长 25 小时。两次 01:30 都被包含。春季切换那天则可能少一小时，不能给所有日期预设相同秒数。

对列本身做 DATE(CONVERT_TZ(occurred_at_utc,...)) 再筛日期，虽然容易写，却把转换放到了每一行上，也不能自然利用这份普通时间索引做相同的范围定位。先算边界，再比较原列，语义与访问方式都更清楚。小表是否真的选索引由优化器决定，不应把这份示例当成固定执行计划承诺。

这里按一个指定报告时区计算整天。如果每个用户都有自己的时区，一份 UTC 记录在不同用户日报中归属不同日期，这是定义的结果，不应把它当成数据库记录移动了。报表缓存键也需要包含报告时区及日期，不能仅使用 UTC 日期复用结果。

旧表使用 TIMESTAMP 时，等号查询还有一个陷阱

MySQL 8.4 的 TIMESTAMP 在命名会话时区下按当地重复小时做等值查询，可能因索引查找与逐行扫描采用不同的转换位置而返回不同结果。这也是为什么事件查询应尽早消除输入歧义，而不是把本地字符串直接交给优化器。

下面另建一张表观察现象，不与前面的 UTC DATETIME 模型混用：

CREATE TABLE timestamp_overlap_sample (
    id BIGINT NOT NULL,
    occurred_at TIMESTAMP NOT NULL,
    PRIMARY KEY (id),
    KEY idx_timestamp (occurred_at)
) ENGINE=InnoDB;

SET @saved_dst_zone = @@SESSION.time_zone;
SET SESSION time_zone = '+00:00';
INSERT INTO timestamp_overlap_sample (id, occurred_at) VALUES
    (1, '2025-11-02 05:30:00'),
    (2, '2025-11-02 06:30:00');

SET SESSION time_zone = 'America/New_York';
SELECT id, occurred_at
FROM timestamp_overlap_sample IGNORE INDEX (idx_timestamp)
WHERE occurred_at = '2025-11-02 01:30:00';

SELECT id, occurred_at
FROM timestamp_overlap_sample FORCE INDEX (idx_timestamp)
WHERE occurred_at = '2025-11-02 01:30:00';

SET SESSION time_zone = @saved_dst_zone;

逐行扫描会把两份 UTC 都转换成当地值比较，可能匹配两行；索引等值定位把查询字面量先转换到一个 UTC 键，不能同时表示这两份时刻。应结合执行计划核对实际使用的路径，不能只看到两个查询结果不同就怀疑数据被另一事务删掉。

IGNORE INDEX 可以帮助证明这个现象，但不适合当作全站长期的时间语义修补。业务若查询确定的一次事件，就传确定 UTC；若查询“当地显示为这个时刻的全部事件”，应把两份合法候选转换成对应 UTC 条件，明确这确实是一对事件集合。两种意图需要不同的输入合同。

接口结果也应保留偏移或 UTC。只返回两行完全相同的 01:30:00，即使数据库正确返回了它们，客户端依然无法解释哪个先发生。展示可以用当地格式，排序、游标和事件身份仍要基于可区分的值。

回拨时刻不适合充当事件身份

唯一的 UTC 时刻也不等于唯一事件：同一微秒内可能发生多个动作，因此表里仍然使用独立 id，排序时用 (occurred_at_utc,id)。本地时刻、格式化字符串和时区缩写更不能替代事件编号。

如果已有数据只存了重复小时里的本地值，没有偏移、UTC、原始消息或其他能够定位的证据，不能靠批量 CONVERT_TZ 宣称完成了无损修复。应标记存在歧义的行，寻找上游记录，或保留未知状态；随机选择一份时间只会把不确定性变成看起来精确的错误。

未来预约则保留当地计划与命名时区，并按执行时采用的规则计算目标时刻。时区规则可能更新，已发生事件的 UTC 不应随之改写，未来日历计划却可能需要重新评估。这两类记录共享日期格式，不共享生命周期。