第一次踩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}'
View Code
通过计算odoo当前用户的时区和utc0之间的时差,然后再做相关的计算处理。这样一来,即使用户在其他的地方使用,也不受影响。
点击链接查看完整源码:github
点击链接阅读原文:菜园工程师