odoo11.0时间差问题，求不更改源代码的解决方式
-
例如在和别的系统对接的时候，
传过来的时间是不能直接拿来用的，
不做时区处理会有时差问题
-
@digitalsatori
确实并非bug，我能理解他的设计，但是在二次开发的时候，我觉得修改贸然修改源码并不合适，可是如果数据库中直接存储的就是零时区的时间，会出现很多问题，如@Siyuan 所说。所以不能只根据现在的需要在获取到的时间上直接处理，应该从数据库中存储的数据上做调整啊
所以才想求解各位如何做的处理，我不太会处理 -
对于多时区这个功能，
数据库里存任何时区其实都是无所谓的；
odoo 目前的做法是：保存到数据库里的是 utc 时间，
所有时间的处理都以utc时间为基础、再进行转换；
如果保存到数据库的时间: 例如是 uct +8,
那么只要将框架所有原来：utc时间为基础、再进行转换 的地方换成：
utc +8 时间为基础、再进行转换；
这样多时区功能照样是可以用的；
说到底就是要保证： 输入、读取用的都是一套时区，
不能只改一部分；
目前odoo 源代码里是写死了 输入、读取都是 utc，
如果将输入 改成别的时区，那么读取也要改着改，
不然就会又时差问题
-
@siyuan 在 odoo11.0时间差问题，求不更改源代码的解决方式 中说：
主要是现在有些企业其实用不到多时区这个功能，
基本上utc +8 就可以了；
odoo 本身的时区处理本身没有问题，
但会导致二次开发的时候所有和时间有关的业务逻辑不走框架的话就要考虑时区转换的问题，
不然容易产生8小时误差
只要有时区设置，它就是一个相对动态的概念。你说得这种应用场景，与其去将Odoo数据库的UTC时间改为UTC+8，为什么不直接在调用时做时区转换呢？
完整的时区支持其实考虑的因素很多，有一定的复杂性，Odoo在这方面实现的还算不错的。 -
主要是在面临大量时间数据处理的时候，
每次都处理时区会比较麻烦，
也可能会遗漏、出问题；
当然“在调用时做时区转换” 也是种正确的解决方案。
odoo 时区方案的解决方案无非以下两种，
-
将框架里 utc 保存、读取的所有逻辑换成你常用的时区：例如cct (utc +8)
-
在时间处理的地方自己考虑时区问题
至于最后用哪种方案就要看具体业务需求了，
谈不上哪种方案好、哪种方案不好
-
-
最简单：例如你抓大量淘宝数据，
抓到的时间都是 utc +8 时间，
在考虑性能、通过sql语句直接存数据库的情况下，
抓到的时间都是要处理时区的，
不能直接就保存到数据库里。
