近期在在开发时使用了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 的配置的时区.
这样默认在创建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
总结一下:
auto_now_add
等, 会返回一个UTC
时间总之, USE_TZ=True
,SQL
里时间都是timestamptz
类型的.
Model
时传入datetime.datetime(2019, 9, 24, 16, 43, 23, 511954)
sql 里会是这样'2019-09-24T16:43:23.511954'::timestamp
时间不带时区了,但是数据库本身是带时区的. 这样怎么保证时间的正确存储呢?
比如我本地获取的时间我知道是一个上海时间, 然后假如 PG 库时区是Japan
, 要是 sql 直接插入的话时间肯定是不对的,因为时间没携带时区信息. 但是在实际使用中发现时间依旧可以正常存储. 原因如下: 在看看 ensure_timezone,当本地时区和数据库时区不一致是, 在执行插入语句时会设置时区和本地一样. 这样就保证了时间的正确.
connection.queries
将 sql 打印出来,结合源码就好分析了.timezone.now()
来获取当前时间.USE_TZ=True
, 所有时间存储都用UTC
时间,展示的时候模板可以根据TIME_ZONE
显示正确的时间.USE_TZ
的值,会有一些奇怪的时间问题 1
neoblackcap 2019-09-25 16:22:24 +08:00
存日期不是应该默认存 UTC 时间么?存本地时间显然会给后面带来麻烦。
|
2
saulshao 2019-09-25 16:33:10 +08:00
正确的做法是在数据库服务器里的时间戳永远都用 UTC 时间,然后显示的时候在前端根据 UTC 时间和浏览器本地时区进行转换。
|
3
510908220 OP @neoblackcap 是的。只是从 django 到数据库存储中间过程里处理不当会有问题。里面有一些隐含的操作,刚好梳理一下,更好的去理解
|