提交flink任务的机器上是时间是UTC时间 为啥提交jar包之后 在flink web ui 显

登录用户hadoop的时区设置不同

Flink在使用时间的这个概念的时候就是基于时间纪元这个概念的。比如首先，我们的时区是东八区，在我们的视野中UTC-0时间应该加8小时的offset，才是我们看到的时间，所以在使用flink的窗口的时候往往比我们当前的时间少8小时。

还有flink的窗口对其，也是基于纪元时间的。5min滚动窗口，.30min滚动窗口，1hour滚动窗口。时间上差了八小时，但是对齐是基于时间纪元的整数单位。

使用flink输出的时差目前没办法，flink不支持配置时区，但是blink支持，等待着合并吧。

时区问题解决方案比较多：flink端不做处理。在读取数据的时候加上8小时的offset。 使用udf等算子给时间戳加上8小时的offset。 sink内部做处理。

所谓的”时间纪元”就是1970年1月1日0时0分0秒，指的是开始的时间。比如Java类代码： Date date = new Date(0); System.out.println(date); 打印出来的结果： Thu Jan 01 08:00:00 CST 1970 也是1970年1月1日，实际上时分秒是0点0分0秒，这里打印出来的时间是8点而非0点，原因是存在系统时间和本地时间的问题，其实系统时间依然是0点，只不过我们的电脑时区设置为东8区，故打印的结果是8点。 只需要将时区设置为GMT+0，即可打印出0点0分0秒 System.setProperty("user.timezone","GMT+0"); 实际上时区问题都是在此时间纪元基础上加/减一定的offset。

Flink在使用时间的这个概念的时候就是基于时间纪元这个概念的。我们的时区是东八区，在我们的视野中UTC-0时间应该加8小时的offset，才是我们看到的时间，所以在使用flink的窗口的时候往往比我们当前的时间少8小时。

实际在使用的时候flink输出的时差很令人反感，但是没办法flink目前不支持配置时区，但是blink支持，等待着合并吧。

Flink在使用时间的这个概念的时候就是基于时间纪元这个概念的。比如首先，我们的时区是东八区，在我们的视野中UTC-0时间应该加8小时的offset，才是我们看到的时间，所以在使用flink的窗口的时候往往比我们当前的时间少8小时。 flink端不做处理。也即是在读取数据的时候加上8小时的offset。 使用udf等算子给时间戳加上8小时的offset。 sink内部做处理。 如果没有时间差异影响，仅仅是北京时间显示，可能是已经调过了，并不会有太大影响