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