UTC时区和本地时间

写local-monitor时，因为涉及到时间序列及序列查询，在转换UTC时间和本地时间的时候出现了一些BUG，记录如下。

时区与 UTC

UTC（协调世界时）：全球统一的时间标准，示例：不受时区影响。2025-09-11T04:44:02Z（Z 表示 UTC，注意如果没有Z，至少js会当作本地时间处理）
时区：地球划分的区域，每个区域有自己的标准时间。例如中国标准时间 CST（UTC+8）。示例：2025-09-11T12:44:02+08:00（带时区偏移）

BUG1：时间选择器与数据库时区不一致

现象：

前端时间选择器选择的是本地时间（如东八区），但提交给后端的时间未做时区转换，直接传递本地时间。
后端数据库统一存储为 UTC 时间，导致查询时出现偏差，

后端相关代码：

# db.py
# 插入数据时，要求 timestamp 必须为 UTC 格式字符串
def insert_ping_result(db_file, ip_address, response_time, timestamp):
    # timestamp 必须为 UTC 格式字符串
    ...

查询历史时，后端也是用 datetime.datetime.utcnow() 作为基准时间：

# db.py
now = datetime.datetime.utcnow()

推测原因：

前端时间选择器组件默认输出本地时间字符串。
前端未将本地时间转换为 UTC 格式再提交。
后端收到的时间与数据库实际存储的 UTC 时间不一致，查询结果异常。

解决建议：

前端提交前，统一将选择器得到的本地时间转换为 UTC 时间字符串（如 ISO 8601 格式）。
后端所有时间字段统一用 UTC 存储和查询。

BUG2：字符串格式导致 JS 解析错误

现象：

后端返回 2025-09-11 04:44:02，前端用 JS 解析后，发现本地时间和原始时间一致，没有加上时区偏移。

原因分析

JS 的 Date 构造函数对于无时区的字符串，默认按本地时区解析。
只有 ISO 格式（带 Z 或时区偏移）才会被当作 UTC 解析。

典型错误代码

const utc = '2025-09-11 04:44:02';
const local = new Date(utc).toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' });
console.log(local); // 实际输出与原始时间一致

四、正确的前端处理方法

1. 后端建议

返回 ISO 8601 格式字符串，如 2025-09-11T04:44:02Z

2. 前端兼容处理

function utcToTimeZone(utcString, tz) {
    if (!utcString) return '';
    // 如果没有 'T' 和 'Z'，手动转为 ISO 格式
    let iso = utcString.replace(' ', 'T');
    if (!iso.endsWith('Z')) iso += 'Z';
    try {
        return new Date(iso).toLocaleString('zh-CN', { timeZone: tz });
    } catch (e) {
        return utcString;
    }
}

// 示例
const utc = '2025-09-11 04:44:02';
const beijing = utcToTimeZone(utc, 'Asia/Shanghai');
console.log('UTC:', utc, '北京时间:', beijing);

3. 推荐实践

后端统一返回 ISO 格式时间。
前端统一用 utcToTimeZone 函数处理所有时间显示。

五、总结

时间字符串格式直接影响前端解析结果。
推荐全链路使用 ISO 8601 标准。
前端如需兼容非标准格式，需手动转换为 ISO 格式再处理。

最后修改于 2025-08-23