我明白你遇到的问题了——明明按照文档设置了USE_TZ=True，但数据库里还是存了带UTC+3偏移的时间，手动在admin转UTC也没生效。咱们一步步来排查和解决：

1. 首先纠正TIME_ZONE的配置错误 #

这是最关键的问题：Django不支持"UTC+3"这种偏移量格式的时区值，它要求使用IANA标准的时区标识符（比如城市时区）。你应该把settings.py里的TIME_ZONE改成对应的时区名称，比如莫斯科时区（UTC+3）对应的是：

TIME_ZONE = "Europe/Moscow"

如果你的时区不需要夏令时调整，也可以用"Etc/GMT-3"（注意这里是GMT-3，因为Etc时区的命名和偏移是反的，GMT-3对应UTC+3）。错误的时区格式会导致Django的时区处理逻辑混乱，这是你当前问题的根源。

2. 模型字段的默认值保持正确配置 #

你模型里的timestamp字段配置是对的：

timestamp = models.DateTimeField(auto_now=False, auto_now_add=False, default=timezone.now)

timezone.now()在USE_TZ=True时会返回带时区感知的datetime对象，Django会自动将其转换为UTC存储到PostgreSQL的timestamptz字段中，不需要手动处理。

3. 移除admin中手动转换时区的代码 #

你当前在save_model里手动转UTC的操作其实是多余的，甚至可能因为时区配置错误而失效。把这段代码删掉，让Django自动处理时区转换：

def save_model(self, request, obj: ManualMeasurements, form, change, debug=True):
    # 移除手动转换时区的代码
    super().save_model(request, obj, form, change)

当用户在admin面板中输入时间时，Django会默认把输入的时间当作TIME_ZONE时区的时间，自动转换为UTC存储到数据库。

4. 验证数据库实际存储的时间 #

PostgreSQL的timestamptz字段本质上是存储UTC时间的，但查询时会根据当前数据库会话的时区自动转换显示。你可以执行以下SQL来查看实际存储的UTC时间：

SELECT timestamp AT TIME ZONE 'UTC' FROM manualmeasurements;

如果返回的是UTC时间，说明存储是正确的，只是你的数据库客户端（比如pgAdmin）用了UTC+3的时区来显示结果。

总结一下修复步骤： #

• 把settings.py中的TIME_ZONE改为合法的IANA时区标识符
• 移除admin中手动转换时区的代码
• 用上述SQL验证数据库存储的UTC时间是否正确

这样调整后，Django就会按照预期：在admin面板显示TIME_ZONE时区的时间，同时将UTC时间存入PostgreSQL数据库。

备注：内容来源于stack exchange，提问作者Donchack