关于odoo处理时间的机制，对以下现象感到困惑：
测试一：
如果在odoo的python代码中，以下代码
datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')
会产生utc时间（不带时区的），结果跟datetime.datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S')是完全一样的！
测试二：
如果在同一台机器的python终端上运行datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')，却会产生一个带时区的本地时间（结果比上面的增加8小时）
同样的python内置的datetime，为什么产生不一样的结果？odoo中间做了什么处理了吗？
另外，上面是的测试时在linux(debian)下。如果在windows中，现象跟上述不一样。
测试一和测试二产生的时间是一致的，结果都是带时区的时间。
========================EDIT=======================
受到以下文章的启发：
http://radzhang.iteye.com/blog/2328612
原来，在odoo/__init__.py初始化时做了个“时区hack”，将系统环境的时区设置成了'UTC'，经这一处理后，上述测试的现象和结果就能解释通了。并且经过这么处理后，在odoo代码中使用datetime.datetime.now()和datetime.datetime.utcnow()是完全一样的效果，不用纠结用哪一个。需要注意odoo/__init__.py中的“时区hack”仅对linux环境起作用。
至于在windows中的现象，其实在最新的odoo版本中，通过命令行启动的odoo实例也能实现上述的“时区hack”，但是在Windows的IDE（比如eclipse）中，odoo官方好像还没有解决的方法来实现这种“时区hack”。具体说法可以参考github中odoo/__init__.py的comments（https://github.com/odoo/odoo/commit/07bf7bf4f3af49f18a06000ef50ef90d8ad90224 ）