??????? 不得不说，这是一个迷之一样的bug。在Django3.2.2中，使用代码“
updated = models.DatetimeField(default=datetime.datetime.now().replace(tzinfo=pytz.timezone('Asia/Shanghai')))”还是可以将UTC时间转换为Asia/Shanghai时区时间的。但是升级至Django3.2.5时，事情就不一样了。如果在不清楚原委的情况下，很容易陷入其中难以自拔的怪圈：不断在Python shell和Django shell交互模式中，来回测试UTC和本地时间的显示和转化，却仍发现从数据库取出的时间戳是UTC（+0）的。
????????这是怎么回事呢？
??????? 以下是Django项目根settings.py的时区设置： ??????
# python3
# LANGUAGE_CODE = 'en-us'
LANGUAGE_CODE = 'zh-hans'
# TIME_ZONE = 'UTC'
TIME_ZONE = 'Asia/Shanghai'
USE_I18N = True
USE_L10N = True
# default=True
USE_TZ = True?????????Python shell 交互模式中，使用datetime.datetime.now()获取本地时间。
????????
????????得到的时间和系统本地时间是一致的。在Django shell模式中进行同样的尝试以便更加详细清晰地查找问题的症结所在。在目标models.py的时间相关字段为updated。updated的默认值为“models.DateTimeField(default=datetime.datetime.now().replace(tzinfo=pytz.timezone('Asia/Shanghai')))”。
????????项目根目录的命令窗口中，输入“(venv)$ python manage.py shell”进入shell交互模式。
????????models.py中关联类class的updated属性初始化正常，显示的是东八区+8的时间，Ubuntu对应的时区名称为“Asia/Shanghai”。简单设置该对象的其他属性保存到数据库。
????????在shell交互模式下，继续查询数据库记录的updated字段的值。在save操作之前，数据库中已包含一条记录。
????????>>> objects=MyClass.objects.all()
??????? >>>objects[1].updated
??????? >>>import pytz
??????? >>>objects[1].updated.replace(tzinfo=pytz.timezone('Asia/Shanghai'))
??????? >>>objects[1].updated.replace(tzinfo=pytz.timezone('UTC'))
???????? 从上面的结果来看，updated字段值在存入数据库前，不知道因何自动被转换成UTC+0时区。这个在Django3.2.2上是正常的，但是到了3.2.5就出现bug。而且不论通过updated.replace(tzinfo=pytz.timezone('[timezone]')都无法将该时间戳转换为本地时区对应的时间。这是一个很奇怪的前后矛盾的bug。
??????? 不过，好在被自动转换的时区是UTC+0，与本地时区东八区相差8个小时。这样，可以通过datetime.datetime.timedelta方法在需要显示该时间的时机来进行纠正。
# python3
import datetime
class ClassName:
def method_name(self):
transformed_updated = updated + datetime.timedelta(hours=8)????????问题解决了！
????????PS：Django这个时区的问题不甚友好。