Postgres和Grafana均设为CET时区时时间偏移缺最近1小时数据问题

绝大多数情况下该问题由Postgres时间戳字段的类型差异导致，和你表层设置的服务时区无关：
Postgres支持两类时间戳存储类型，二者的时区处理逻辑完全不同：

• timestamp without time zone（普通timestamp类型）：不存储任何时区信息，写入时直接丢弃传入的时区偏移，按输入的字面量存储
• timestamp with time zone（别名timestamptz）：写入时自动转换为UTC时间存储，查询时再按当前会话/服务配置的时区转换为对应本地时间

你遇到的1小时差正好对应CET时区和UTC的偏移（CET为UTC+1，夏令时期间为UTC+2），具体触发逻辑如下：
Grafana调用Postgres数据源查询时，无论界面设置的是什么时区，默认传递的时间范围参数都是带时区标记的UTC时间。如果你表中的时间戳字段是timestamp without time zone类型，Postgres在做过滤比较时，会自动将Grafana传入的带时区参数转换为不带时区的UTC字面量，相当于过滤条件的上限比你预期的CET时间少了1小时。
举个实际场景：你数据库中存储的CET时间14:00对应UTC的13:00，Grafana查询CET时间截止到14:00的数据时，传入的上限参数为202X-XX-XX 14:00:00+01，Postgres和无时区字段比较时会把该参数转换为UTC时间13:00作为过滤上限，自然只能查到13:00及之前的数据。

优先方案（推荐） #

将表中的时间戳字段类型修改为timestamptz，符合Postgres时区处理的最佳实践，无需修改其他配置即可自动对齐Grafana的时间查询逻辑。

临时兼容方案（无需改表） #

如果无法修改表结构，可以选择以下任意一种方式修复：

• 在Grafana的查询语句中手动给时间字段加时区转换，示例如下：

SELECT 你的指标列 FROM 你的表名
WHERE 时间戳字段 AT TIME ZONE 'CET' BETWEEN $__timeFrom() AND $__timeTo()

• 进入Grafana对应Postgres数据源的配置页，开启「Convert timestamp without time zone to UTC」开关，也可直接解决偏移问题。

如果调整后仍有问题，可以补充排查两个配置：

• 检查Grafana面板的时间范围是否设置了额外的延迟偏移，部分场景下会默认配置1小时的查询延迟避免拉取未完成写入的数据
• 确认数据写入逻辑没有做多余的时区转换，避免数据库中存储的实际是UTC时间，而非你以为的CET时间

内容的提问来源于stack exchange，提问作者Michael Hecht