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的值,会有一些奇怪的时间问题