fix: 修复 ISO8601 日期时间导入时区偏移

This commit is contained in:
2026-06-25 15:47:58 +08:00
parent 3c281956c7
commit a43a79448c
3 changed files with 11 additions and 4 deletions
-3
View File
@@ -53,9 +53,6 @@ UPDATE `5G_UD` SET
CREATE TABLE `4G` AS SELECT * FROM `4G_UD`;
CREATE TABLE `5G` AS SELECT * FROM `5G_UD`;
UPDATE `4G` SET `日期时间` = DATE_FORMAT(DATE_ADD(`日期时间`,INTERVAL 8 HOUR), '%Y-%m-%d %H:%i:%s');
UPDATE `5G` SET `日期时间` = DATE_FORMAT(DATE_ADD(`日期时间`,INTERVAL 8 HOUR), '%Y-%m-%d %H:%i:%s');
ALTER TABLE `4G`
ADD COLUMN `日期` date NULL FIRST,
MODIFY COLUMN `日期时间` datetime,
+4 -1
View File
@@ -754,7 +754,10 @@ class DataProcessor:
try:
if fmt == 'ISO8601':
temp_parsed = pd.to_datetime(series[remaining], errors='coerce', format='ISO8601')
raw = series[remaining].astype(str)
raw = raw.str.replace(r'(?:Z|[+-]\d{2}:\d{2})\s*$', '', regex=True)
raw = raw.str.replace('T', ' ', regex=False)
temp_parsed = pd.to_datetime(raw, errors='coerce')
else:
temp_parsed = pd.to_datetime(series[remaining], errors='coerce', format=fmt)
+7
View File
@@ -861,3 +861,10 @@
- 消除标记-删除模式:4G 部分的 DLPRB_MAX 和 CCE_MAX、5G 部分的 DLPRB_MAX 原先各用 `ADD COLUMN insert → UPDATE...JOIN → ADD INDEX → DELETE → DROP COLUMN` 五步标记并删除重复行,现改为 `INSERT...WHERE NOT EXISTS` 一步完成,共减少约 15 条冗余 DDL/DML。这正是导致 CCE_MAX JOIN 4G_MAX UPDATE 跑 >1 小时的直接原因。
- 标识符规范化:全文所有表名和列名统一加反引号,避免以数字开头的表名(如 `4G`、`5G`)和中文列名在不同 MySQL 版本或 SQL 模式下引起解析歧义。
- 业务逻辑未变:忙时取法(ULPRB > DLPRB > CCE 优先级)、结果表聚合和 IFNULL 归零逻辑均保持原样。
## 2026-06-25:修复 ISO8601 日期时间导入时区偏移
- 根因:源 CSV 中日期时间格式为 `2026-06-15T00:00:00+08:00`(ISO 8601 带时区),`pd.to_datetime(format='ISO8601')` 会自动转为 UTC(`2026-06-14 16:00:00`),导致入库后比实际壁钟时间偏移 -8 小时。
- 修复:`processor.py::_convert_datetime_column` 在 ISO8601 解析前先用正则剥离时区后缀(`+08:00`、`-05:30`、`Z`)和 `T` 分隔符,再按朴素日期时间解析,保留原始壁钟时间。
- SQL 清理:`ReportScript.sql` 删除 4G/5G 的 `DATE_ADD(INTERVAL 8 HOUR)` 补偿语句,因为数据导入阶段已正确保留本地时间,不再需要 SQL 层面修正。
- 验证:`python -m compileall -q app` 通过。