python读取postgre数据库中时间格式转换问题

python提供了多种读取数据库的方法，但是时间在python中的数据类型和数据库中的数据格式不统一，所以经常需要我们在python读入数据之后手动转换数据的时间类型。本文详细介绍了几种数据转换的方法和需要注意的问题。

一、python读取数据库

方案一：在数据库读取时转化

在数据库读取时讲date类型的数据转化为时间戳，这样python读取到的就是integer类型，由于整数不涉及时区问题，所以这样可以最大程度地保证处理前后的时间是对齐的，具体做法如下：

在数据库中执行：

--将timestamp with time zone类型的数据转化成integer
select floor(extract(epoch from time_1)) as time_1
from table_1；

在python中执行：

#将int或者float类型表示的时间戳转化为不带时区的datetime类型
time_1 = datetime.datetime.fromtimestamp(time_1)

注意这样得到的最终时间是不带时区的。

方案二：在python中预处理时间

有时一个sql语句中可能含有多个时间字段，它们的处理方式可能是相同的，每一条都提出来单独写floor()函数过于繁琐，此时直接用df.apply()的功能显然要便捷许多，那么可以采取如下的做法：

在数据库中执行：

--不做任何处理
select time_1
from table_1

得到的结果：

可以看到此时python读入后的时间类型是带时区的，是0时区，但是请注意，虽然不带时区的时间类型也是默认0时区，但这两种时间类型是无法直接做加减运算的，必须转化为统一时区才能进行计算。

在python中执行：

#将带0时区的datetime类型转化为不带时区的datetime类型
time_1 = time_1.tx_localize(None)

得到的结果：

这种情况很便捷，但是要考虑corner case：time_1为空的情况
这种情况下该数据类型为NaT，有关NaT的介绍我在之前的文章关于Python中的空值问题中进行过分析，此处不再赘述。当数据类型为NaT时直接执行tx_localize()函数会报错。

二、python将处理后的数据上传

为了方便统一，python中的数据均以0时区的时间进行计算（不带时区的datetime格式），但是在上传时，我们有必要根据情况将其改成8时区。
比如数据库中存储的是2022-01-01 00:00:00，时区为8时区

采用方案一

传入的timestamp是0时区的integer，但是python会自动将其转化成8时区对应的时间！！！
也就是说该integer转化为datetime后的时间应该和数据库中存储的时间在字符串部分一致，只是时区不同。
python进行计算的时间是2022-01-01 00:00:00，时区为0时区
在上传时数据库并不会对python中上传的数据做任何自动转化，所以上传到数据库中的时间也是2022-01-01 00:00:00.
由于数据库是8时区的时间表示，所以上传的结果的物理意义就是8时区的2022-01-01 00:00:00，与最开始保持一致 ，保证了数据的一致性。

采用方案二

tz_localize()函数并不会改变时间字符串的内容，只会改变时区，举例来说假设time_2 = 2022-01-01 00:00:00，时区为8时区，在执行tz_localize(None)后time_2 = 2022-01-01 00:00:00，时区为0时区。（受条件限制未完全验证，若有误，烦请指出，十分感谢）
这时上传数据库也和方案一相同，数据库得到的就是2022-01-01 00:00:00的8时区数据。

注意

1. 数据库中的时间本身表示的是0时区的时间
   上述的情况比较清晰，由于python会自动将时间戳转化为本地时区对应的时间，所以针对数据库中的时间本身就是0时区的时间数据的情况若采用方案一则比较绕。
   即数据库中的数据无论是什么时区的，如果还需后续上传保证一致性，在数据库中转化时间戳时均需-28800才能得到正确的数据。因为python会默认你读到的数据是0时区的，而且默认你想要的时间是8时区的，尽管转化得到的时间类型是无时区的。
2. 数据库涉及到多表，有的是0时区时间，有的是8时区时间
   这种情况比较麻烦，一定要注意保证数据前后的一致性，无论采取哪种方案，转化为无时区的时间后得到的时间都是不一致的！！！
   如果要保证一致性，需要给8时区的数据额外-28800或者-interval 8hours或者 -pd.Timedelta(‘8 hours’)