第一次踩odoo时差的坑，才知道原来odoo在存储日期数据时，是以UTC0时区存放的，和北京时间相差8个小时。只是odoo本身能很好的处理日期数据的存储和展示，所以刚开始接触odoo，不容易发现这个问题。
在做货运管理的时候，生成货运订单编号的格式是自己定义的，根据当日的运单数量自动往下递增，如下所示：
但是在第二天早上，新增加运单的时候，发现运单号上面的日期依然是昨天的，很是奇怪，搜索了下相关的资料，才发现是时差的原因导致的，虽然可以通过已知的8个小时的时差做计算，但这显然不是我们想要的，如果系统使用的地方采用的不是东8区的时间怎么办呢？以下是采用的最终方案代码：
1 # 生成自定义编号数据 2 def generate_custom_code(self): 3 # 获取当前用户时区 4 tz_name = self._context.get('tz') or self.env.user.tz 5 # 计算当前时区和UTC0时差 6 utc_time = fields.Datetime.now() 7 local_time = utc_time.astimezone(pytz.timezone(tz_name)) 8 date_format = "%Y-%m-%d %H:%M:%S" 9 string_utc = utc_time.strftime(date_format) 10 string_local = local_time.strftime(date_format) 11 datetime_utc = datetime.strptime(string_utc, date_format) 12 datetime_local = datetime.strptime(string_local, date_format) 13 time_difference = (datetime_local-datetime_utc).total_seconds()/3600 14 tz_hours = timedelta(hours=time_difference) 15 hours = timedelta(hours=24-time_difference) 16 # 构造查询数据条件 17 current_time = fields.Datetime.now() 18 local_date = (current_time + tz_hours).replace(hour=0, 19 minute=0, second=0, microsecond=0) 20 date_start = local_date-tz_hours 21 date_end = local_date+hours 22 record_count = self.search_count( 23 [('create_date', '>=', date_start), ('create_date', '<', date_end)]) 24 return f'HY{local_date.strftime("%Y%m%d")}{record_count + 1:04d}'
通过计算odoo当前用户的时区和utc0之间的时差，然后再做相关的计算处理。这样一来，即使用户在其他的地方使用，也不受影响。
点击链接查看完整源码：github
点击链接阅读原文：菜园工程师
