Django/DRF中如何将UTC存储的时间戳转为用户配置的本地时区时间

问题核心原因 #

你的转换逻辑出错，本质是对**无时区标记（naive）**的datetime对象直接调用astimezone时，Python不会默认认为它是UTC时间，而是会用运行环境的本地时区给它补时区标记，导致转换基准完全错了，自然得不到正确结果。
你代码里第一步打印的2022-06-17 05:39:09就是不带任何时区信息的naive时间，直接调用astimezone(America/Buenos_Aires)时，Python会先把这个时间当成你服务器本地时区的时间，再转成阿根廷时区，所以最后偏移量完全不对。

正确转换逻辑 #

所有跨时区转换的前提是：待转换的时间必须是**带明确时区标记（aware）**的UTC时间，转换步骤固定为：

• 确保待转换的时间已经绑定UTC时区标记：如果是Django ORM在USE_TZ=True配置下取出的时间，本身已经是带UTC标记的aware对象，不需要额外处理；如果是手动生成的naive时间，先用django.utils.timezone.make_aware绑定UTC时区
• 调用astimezone(目标时区)做转换，涉及夏令时的场景用目标时区的normalize方法修正偏移
• 按需格式化输出可读时间字符串即可，不需要手动解析偏移量做计算

对应你场景的正确代码：

import pytz
from django.utils import timezone

# 假设ts_a、ts_b是从数据库取出的naive UTC时间，先绑定UTC时区
# ORM取出的aware时间可跳过这两行
ts_a = timezone.make_aware(ts_a, pytz.UTC)
ts_b = timezone.make_aware(ts_b, pytz.UTC)

# 初始化用户配置的目标时区
user_tz = pytz.timezone('America/Buenos_Aires')
# 转换+夏令时归一化
ts_a_local = user_tz.normalize(ts_a.astimezone(user_tz))
ts_b_local = user_tz.normalize(ts_b.astimezone(user_tz))

# 输出可读的本地时间，不带偏移量
print(ts_a_local.strftime("%Y-%m-%d %H:%M:%S"))
print(ts_b_local.strftime("%Y-%m-%d %H:%M:%S"))

运行后输出完全符合你的预期：

2022-06-17 02:39:09
2022-06-17 02:46:49

DRF 全局适配方案 #

如果需要给所有接口的时间返回自动自动适配用户时区，不需要每个接口单独写转换逻辑，自定义序列化器的DateTime字段即可：

import pytz
from rest_framework import serializers

class UserLocalTimeField(serializers.DateTimeField):
    def to_representation(self, value):
        # 从请求上下文获取当前用户，读取用户配置的时区，默认 fallback 到UTC
        request = self.context.get('request')
        user_tz_str = getattr(request.user, 'timezone', 'UTC') if request else 'UTC'
        user_tz = pytz.timezone(user_tz_str)
        # 转换到用户本地时区，自动处理夏令时
        local_time = user_tz.normalize(value.astimezone(user_tz))
        # 按需调整输出格式
        return local_time.strftime("%Y-%m-%d %H:%M:%S")

之后在所有序列化器中用这个字段替换默认的DateTimeField，就可以自动适配任意用户配置的时区，不需要手动计算偏移，夏令时切换时也不会出现时间错误。

注意事项 #

• 绝对不要用固定小时数的timedelta做时间偏移，遇到夏令时切换、时区规则调整时必然出问题，pytz已经内置了所有IANA时区的历史和未来规则，normalize方法会自动处理偏移
• 后端存储、业务逻辑处理全程用UTC时间，只在最后序列化返回给前端的环节做用户本地时区转换，不要在业务层混用不同时区的时间
• 不要用“解析偏移量字符串做差值”的兜底方案，逻辑冗余且容易出错，标准的时区转换API已经覆盖了所有场景

内容的提问来源于stack exchange，提问作者Nicolás Fernández Sanz