postgresql的timestamp类型与python的datetime类型之间的坑

postgresql的timestamp类型与python的datetime类型之间的坑

最近的项目突然发现一个bug,就是当服务器系统时区是utc时区,而服务器pgsql的时区是+8时区时候,通过python的datetime.now()插入的timestampz值有问题。所以特意做了一个测试。

1 测试前提

1.1 python的datetime类型

首先,要了解python的datetime类型是包括时间与时区的。而通过datetime.now()与datetime.utcnow()获得的时间其tzinfo属性为null,即不带时区属性。要想获得带时区属性的datetime类型,就必须使用datetime.now(tz=timezone.utc)或者datetime.now(tz=timezone(timedelta(hours=8)))。

1.2 pgsql的时间戳类型

然后,pgsql的时间戳类型包括timestamp(无时区), timestampz(有时区)两种。

1.3 测试表与测试代码

为了进行测试,我新建了一张time_test表,然后分别插入pythono的datetime.now(), datetime.utcnow(), datetime.now(timezone.utc)三个值。

2 测试

2.1 系统时区+8,pgsql时区+8

明显这时候python使用datetime.utcnow()值插入数据库,得到的并不是我们想要的结果。

2.2 系统时区utc, pgsql时区+8

这时候只有使用datetime.now(timezone.utc)插入数据库得到的才是我们想要的结果。

2.3 系统时区utc,pgsql时区utc

修改postgresql.conf文件中的timezone为’UTC’,然后通过命令  pg_ctl  restart  -D 数据库目录  来重启postgresql。

使用如下sql语句检查当前的pgsql时间与时区:select now();  show time zone;

这是最完美的情况,任何一种方式都是我们想要的结果。

2.4 系统时区+8,pgsql时区utc

这种情况是最混乱的,对于timestampz的时间来说,很明确utcnow与nowz插入的值都是正确的。而对于timestamp类型的时间戳而言,可能开发者自己都不清楚想要的是+8时间还是utc时间。。。

3 结论

python要用datetime.now(tz=timezone.utc)来获取带时区的当前时间,postgresql的时间戳用timestampz。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注