所以总结下，实际不仅仅是 https://issues.apache.org/jira/browse/FLINK-17767
这一个问题，这个正式我讲到的UTC+8时区下天级别窗口正确划分的解决方案。
但FlinkSQL本身的eventtime的类型问题反而感觉更严重，造成各种误解等。时间戳是最准确的信息，既然采用了日期这种不准确的东西，就应该明确其时区信息。即使时区信息是被隐藏了，那么就正确考虑时区，而不是在将日期翻译回时间戳的时候默认采用了UTC+0的时区转回去，毕竟日期可能是UTC+8时区的表示。
nobel一旦 于2020年8月14日周五 上午11:49写道：
>
窗口周期实际需求是UTC+8时区的（8月）14日0点～14日24点，实际对应UTC+0时区的（8月）*13日*16点～14日16点。
1 解释下为什么在FlinkSQL场景下时区设置正确情况下，窗口没划分错误。
*这个原因比较绕，这也是我想不通的点，作为疑问，希望有人解答（即为什么FlinkSQL使用TIMESTAMP(3)这种日期作为event
timed定义，以及watermark计算的依据，而不是bigint的UTC+0的时间戳作为eventtime，和datastream
api保持统一呢）*。
不管是SQL还是DataStream，底层最终用来划分窗口的时候的时间，都是unix timestamp。
SQL里面的Timestamp类型，是可以带着时区的，但是转成unix timestamp表示的时候，时区信息就丢掉了。
Zhao,Yi(SEC) 于2020年8月13日周四 上午10:12写道：
> 大概懂你意思，sql情况下event time都是Timestamp数据类型，这是一种-MM-dd
>
大概懂你意思，sql情况下event time都是Timestamp数据类型，这是一种-MM-dd
HH:mm:ss格式的，从这个角度讲的确是不需要考虑offset的问题（只要周期是1min/1h/1d等类似）。只需要这个Timestamp是我需要的时区格式的日期即可。
其实我是联系DatastreamAPI的，因为DatastreamAPI中是基于unix timestamp（时间戳）来划分的。
在 2020/8/12 下午9:21，“Benchao Li” 写入:
Hi，
目前还没有支持offset，有一个issue[1] 在跟进解决这个问题。
Hi，
目前还没有支持offset，有一个issue[1] 在跟进解决这个问题。
但是你这个case应该是不需要offset就可以的，现在划分窗口的逻辑是直接按照毫秒级别的时间戳来整除进行计算的。
所以如果窗口是1min/1h/1d 这种，都是整点的窗口，没有问题的。如果你有这个问题，那应该是你的时间字段有时区问题。
有一种case是需要offset的，比如一周这种窗口，因为1980-1-1是周四，所以一周的窗口是从周四开始的。
[1] https://issues.apache.org/jira/browse/FLINK-17767
Zhao,Yi(SEC)
