Django设置时区后视图中timezone.now()返回UTC的原因及用法

核心结论 #

当USE_TZ = True时，timezone.now()本来就会返回UTC时区的带时区感知datetime对象，这是Django的设计规范；而模型的DateTimeField会自动处理时区转换，所以存储和读取时能正常显示你设置的本地时区时间。

你的配置与现象回顾 #

当前settings.py配置：

TIME_ZONE = 'Asia/Calcutta'

USE_I18N = True

USE_L10N = True

USE_TZ = True

执行的时区激活代码：

from django.utils.timezone import activate
activate(settings.TIME_ZONE)

输出示例：

datetime.datetime.now() # 2022-08-29 02:03:44.941847
timezone.localtime(timezone.now()) # 2022-08-29 02:03:44.941847+05:30
timezone.now() # 2022-08-28 20:33:44.941847+00:00
timezone.get_current_timezone() # Asia/Kolkata

问题拆解 #

1. 为什么视图里timezone.now()是UTC？

   • 开启USE_TZ=True后，Django内部统一以UTC作为时间处理基准，timezone.now()本质是返回带UTC时区信息的当前时间，这是为了避免多时区场景下的时间混乱，属于框架标准行为。
   • 你调用的activate(settings.TIME_ZONE)只是设置了当前线程的显示时区（用于模板渲染、localtime()转换等场景），但不会改变timezone.now()的返回值——它始终输出UTC时间。

2. 为什么模型存储正常？

   • 当你将timezone.now()返回的UTC时间存入DateTimeField时，Django会自动完成时区转换：存储时持久化UTC时间，读取时则根据TIME_ZONE配置，自动将UTC时间转换为你指定的Asia/Calcutta时区的带感知datetime对象，所以从模型读取到的是本地时间。

正确用法规范 #

• 获取当前时间： 始终使用timezone.now()，拿到UTC时区的带感知datetime对象，这是Django推荐的最佳实践，能避免跨时区场景下的时间错误。
• 显示本地时区时间： 如果需要在视图中展示本地时间，用timezone.localtime(timezone.now())，它会根据当前激活的时区（即你设置的Asia/Calcutta）将UTC时间转换为本地时间，就像你示例中得到的结果。
• 禁止使用datetime.datetime.now()： 这个方法返回的是不带时区信息的本地时间，在USE_TZ=True的环境下，很容易引发时区不匹配的错误，绝对不要在Django项目中用它来获取当前时间。

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