【TDengine 使用环境】
测试环境
【TDengine 版本】
TSDB-OSS ver: 3.3.7.5
【操作系统以及版本】
CentOS 7.9 64位
【部署方式】
非容器部署
【集群节点数】
1
【集群副本数】
1
【描述业务影响】
在全球化多时区业务中，按自然月（1n）降采样聚合的数据边界与电站当地自然月发生错位，导致海外电站的月度统计报表数据不准。
【问题复现路径/shan】做过哪些操作出现的问题
服务端系统时区为 Asia/Shanghai (+08:00)。
问题一：查询 Asia/Amman (+03:00) 时区本年每月的电量数据。使用 interval(1n) 降采样时，TDengine 默认按照服务端的 +08:00 零点切分窗口。当业务层将聚合结果转换回 +03:00 时区显示时，由于 5 个小时的时差，导致跨月边界数据发生错位。
问题二：为解决上述错位问题，我们计划使用 offset 偏移量来对齐窗口。但当查询东边时区（如日本 +09:00）时，时差为负数（需向西退 1 小时）。尝试执行 INTERVAL(1n, -1h) 试图对齐，发现引擎目前不支持负数 offset，导致 SQL 报错。
【遇到的问题：问题现象及影响】
现象:
-
不加 offset，查其他时区会导致自然月统计数据跨月错乱。
-
加上负数 offset，查服务端以东的时区会直接报错（提示 Interval offset cannot be negative）。
核心诉求：
针对这种跨时区查询自然月（1n）降采样的痛点，在不轻易更改服务器 OS 时区、且业务端使用JDBC 连接池（不方便频繁使用 SET TIME ZONE 避免全局污染）的情况下，官方有没有更好的最佳实践或解决方案？
【报错完整截图】（不要大段的粘贴报错代码，论坛直接看报错代码不直观）
