npgsql/dapper/postgresql的时区问题

最大的问题:

dapper通过npgsql 用now()函数 写入到Create_date字段(timestamp without timeznone),则写入的是utc时间(0时区时间,比东8区少8小时)

倘若将create_date的字段改为带时区 TIMESTAMP WITH TIME ZONE

USING create_date AT TIME ZONE 'Asia/Singapore';

则dapper用now()能正常写入东8区时间

但是,鬼扯的问题又来了,dapper查出来的 记录,如果用query返回dynamic类型,create_date返回的datetime的kind是utc,

如果用ExecuteReader返回reader然后新建一个datatable,将此reader载入,则狗血的bug来了,转出来的DataRow,这个create_date的kind是unspecified!

就因为这个问题,即使将create_date字段属性改为带时区,反应到前端,也是0时区的时间,少了8小时!!

相关推荐
笃行35011 小时前
金仓数据库数据安全双防线:静态存储加密与传输加密实战
数据库
笃行35011 小时前
金仓数据库物理备份实战:sys_rman 全流程演练与误覆盖抢救
数据库
笃行35011 小时前
金仓数据库逻辑备份实战:从全库导出到 Schema 替换的完整闭环
数据库
SelectDB1 天前
阶跃星辰基于 SelectDB 构建 PB 级 Agent 可观测平台
大数据·数据库·aigc
这个DBA有点耶1 天前
GROUP BY优化全解:如何写出既不丢数据又飞快的分组查询
数据库·mysql·架构
掉头发的王富贵2 天前
【StarRocks】极限十分钟入门StarRocks
数据库·sql·mysql
Nturmoils2 天前
WHERE 条件别凭习惯写,常用查询先跑一遍
数据库
Databend2 天前
在 AWS 中国峰会逛了一天,我在 Databend 展台看到了 Agent 数据基础设施的新思路
数据库·人工智能·agent
ClouGence4 天前
Oracle 数据同步为什么会出现数据不一致?长事务是常被忽略的原因
数据库·后端·oracle