这个以前没系统处理过，感觉前端页面显示正常，就OK。

但有的不重要的地方，显示有8小时错乱，也没有列入优先级处理。

昨天下细看了一些网上文档，找取了解决思路。

大致想法是：数据库里存+00：00时区的时间，而读到时间之后，具体的时区，由APP框架这一层来处理。

具体到DJANGO+MYSQL来说：

会关系到MYSQL的操作系统时区（MYSQL会读取这个设置，形成system_time_zone）  system_time_zone | CST，

MYSQL的时区： time_zone        +00:00

django框架的四个设置：

TIME_ZONE = 'Asia/Shanghai'

USE_I18N = True

USE_L10N = True

USE_TZ = True

mysql相关命令：

show variables like '%time_zone%';
select now();
set time_zone='+00:00';
set time_zone='SYSTEM';

操作系统输出：

# date
Fri Aug  :: CST 

参考URL：

https://blog.csdn.net/ichuzhen/article/details/38555645

=================================================

五、Django 中使用 MySQL 存储时间遇到的问题

在此先说明一下，我所用的数据库时 CST 时区，与所在的服务器系统时间一致，Django 所在的 WEB 服务器也是统一台机器。在之前使用的过程中，从 Django 中获取到的 localtime 存储到数据库时会被系统自动处理增加8小时。针对这一问题，搜集了各方面的资料。下面就对 Django 的时区机制作个解释。

其实，Django 在配置文件 settings.py 中对时间时区有影响的是两个参数，一个是 TIME_ZONE，另一个是 USE_TZ。根据USE_TZ 官网文档中的描述，这一属性默认值是 False。如果设置为 Ture，Django 内部将会使用对时区敏感的时间，否则 Django 将会使用系统本地的原有时间。（注意：为了方便，由 django-admin.py startproject 创建而来的项目 settings.py 中此项值设置为了 Ture）

与这一属性相关的还有 TIME_ZONE, USE_I18N 和 USE_L10N，下面我们来看一下这几个属性。

TIME_ZONE 官方文档中说，在 Django 1.4 以后的版本中，这一属性值的意义是由 USE_TZ 决定的。这并不是服务器必须的，因为一个服务器可以服务多个 Django 框架的服务，并拥有各自的时区。

首先说明一点，在开启了 Django 所有关于时区的设置之后，本来以为 Django 将会以 UTC 标准时区连接数据库，但是经笔者测试（在 Django 中引入 django.db.connection 连接做查询）发现实际连接的时区是数据库系统的全局设置。确认这一点十分关键，因为它事关全部时间数据的时区问题。

如下是做的一些测试以说明问题。

由此可见，使用情形4的配置，设置 USE_TZ = Ture，数据库 time_zone = '+00:00'，时间设置为 time.strftime('%Y-%m-%d %X', time.gmtime())，可以加时区 '+00:00'（数据库不会关心），在数据库中采用 DATETIME 类型存储最为合适。