django mysql 时区_django 下 PostgreSQL 时区问题整理

DJANGO 下 PostgreSQL 时区探究

近期在在开发时使用了PostgreSQL数据库,在时间上遇到了一些问题. 整理一下, 避免再次踩坑，给需要的人做个参考.

时区设置

def ensure_timezone(self):

if self.connection is None:

return False

conn_timezone_name = self.connection.get_parameter_status('TimeZone')

timezone_name = self.timezone_name

if timezone_name and conn_timezone_name != timezone_name:

with self.connection.cursor() as cursor:

cursor.execute(self.ops.set_time_zone_sql(), [timezone_name])

return True

return False

django里Model在执行前会调用此函数的. 可以看到如果数据库的时区和本地的时区不一样,会将数据库时区临时设置为 TIME_ZONE 的配置的时区.

USZ_TZ = True

这样默认在创建Model时时间字段手动填写的话最好都使用timezone.now():

def now():

"""

Return an aware or naive datetime.datetime, depending on settings.USE_TZ.

"""

if settings.USE_TZ:

return datetime.utcnow().replace(tzinfo=utc)

else:

return datetime.now()

可以看到返回的是一个带着时区UTC的时间. 这样插入语句就像下面这样:

INSERT INTO "hhh_person" ("first_name", "last_name", "updated", "created") VALUES ('qq', 'utc', '2019-09-24T08:29:34.112701+00:00'::timestamptz, '2019-09-24T08:30:22.050999+00:00'::timestamptz)

可以看到插入语句里的时间是携带时区信息的.

如果手动传入一个不带时区的时间,比如datetime.now(), django会调用make_aware加上时区的. 例如:

代码里传入的是 datetime.datetime(2019, 9, 24, 16, 29, 46, 66616)

最终的 sql 是:

'2019-09-24T16:29:46.066616+08:00'::timestamptz

总结一下:

如果传入的是本地时间, 程序内部会自动加上配置的时区(TIME_ZONE)

如果是自动获取时间,比如设置了auto_now_add等, 会返回一个UTC时间

如果是其他时区, 会保持这个时区

总之, USE_TZ=True,SQL里时间都是timestamptz类型的.

USZ_TZ = False

如果传入的是不带时区的时间

创建Model时传入datetime.datetime(2019, 9, 24, 16, 43, 23, 511954)

sql 里会是这样

'2019-09-24T16:43:23.511954'::timestamp

时间不带时区了,但是数据库本身是带时区的. 这样怎么保证时间的正确存储呢?

比如我本地获取的时间我知道是一个上海时间, 然后假如 PG 库时区是Japan, 要是 sql 直接插入的话时间肯定是不对的，因为时间没携带时区信息. 但是在实际使用中发现时间依旧可以正常存储. 原因如下: 在看看 ensure_timezone，当本地时区和数据库时区不一致是, 在执行插入语句时会设置时区和本地一样. 这样就保证了时间的正确.

如果时间是携带时区的, 数据库会正确处理时区转换的.

总结

postgresql 里时间带时区, 有时遇到一些奇怪的问题，调试的话可以使用connection.queries将 sql 打印出来，结合源码就好分析了.

给时间字段赋值时,统一使用timezone.now()来获取当前时间.

开启USE_TZ=True, 所有时间存储都用UTC时间，展示的时候模板可以根据TIME_ZONE显示正确的时间.

代码里不要随便动态修改USE_TZ的值,会有一些奇怪的时间问题