Django中Naive DateTime字段时区转换及存储问题求助

UTC时区设置的来源 #

1. pandas解析环节：如果你的时间字符串（如29/01/2024 14:00:00）被pandas默认解析为无时区的naive datetime，后续代码若强制将其转换为UTC时区（比如用pd.to_datetime(..., utc=True)，或handler逻辑给naive datetime附加UTC时区），就会出现你看到的UTC时间戳。
2. Django时区机制：当USE_TZ = True时，Django默认要求所有存入数据库的datetime必须是带时区的aware对象，且会自动将其转换为UTC存储——这是Django时区支持的标准行为，目的是确保数据库存储的时间统一为UTC，避免时区混乱。

实现数据识别为CET时区的解决方案 #

1. 修正pandas解析逻辑，生成CET时区的aware datetime #

在解析时间字符串时，直接指定时区为CET，确保生成的Timestamp是带CET时区的aware对象：

import pandas as pd

# 假设时间列名为'date'，格式为dd/mm/YYYY HH:MM:SS
df['date'] = pd.to_datetime(df['date'], format='%d/%m/%Y %H:%M:%S')
# 给无时区的datetime附加CET时区
df['date'] = df['date'].dt.tz_localize('CET')

执行后，df['date']的输出会是：Timestamp('2024-01-29 14:00:00+0100', tz='CET')，与你上传的原始时间时区匹配。

2. 移除handler中强制转换UTC的逻辑 #

检查将DataFrame转为dict的代码，确保没有将CET时区的datetime转换为UTC的操作（比如dt.tz_convert('UTC')），直接保留CET时区的aware datetime即可。

3. 验证Django存储与读取逻辑 #

当你将带CET时区的aware datetime存入数据库时：

• Django会自动将其转换为UTC时间（即2024-01-29 13:00:00+00）存储到PostgreSQL，这是标准且推荐的做法。
• 当从数据库读取该时间时，Django会自动根据TIME_ZONE = 'CET'将其转换回CET时区的时间（2024-01-29 14:00:00+01）供应用使用。

解决"naive datetime"报错 #

该报错是因为Django开启时区支持后，不允许存入无时区的naive datetime对象。通过上述步骤生成aware datetime后，这个报错会自动消失。

内容的提问来源于stack exchange，提问作者GeoGyro