Hi, I'm not quite sure if I understood the question correctly. The second parameter of
TumblingEventTimeWindows.of(Time size, Time offset) has an independent time scale of the first parameter. It doesn't matter if your actual windowing time is in minutes or seconds. However, if your size is much smaller than offset; it doesn't matter in reality. The size is used to group elements into non-overlapping windows. So with 5s you get 20 windows per minute and 1200 per hour. The offset is added to the data prior to binning while forming the windows (so the actual data is untouched). If you add anything in the offset that is a multiple of the size, the binning is exactly the same. So if you have data coming in at 00:00:01, 00:00:03, 00:00:07, you always get 1 window of [00:00:01, 00:00:03] and one window of [00:00:07] as long as you offset is in multiples of 5s. If your offset is 2s, you'd get different windows though [00:00:01] and [00:00:03, 00:00:07]. If we go back to your initial example you can see the difference if you consider 03:00:00, 11:00:00, 19:00:00, then they are all in the same bin without offset. But if you shift all elements by -8h, you end up with [03:00:00], and [11:00:00, 19:00:00]. On Mon, Oct 11, 2021 at 3:27 PM 杨浩 <yangha...@163.com> wrote: > As in China (UTC+08:00)，we should use Time.hours(-8) as offset when state > day's data, > > // daily tumbling event-time windows offset by -8 hours.input > .keyBy(<key selector>) > .window(TumblingEventTimeWindows.of(Time.days(1), Time.hours(-8))) > .<windowed transformation>(<window function>) > > > > shall we also set Time.hours(-8) as offset for minute's state ? > > input > .keyBy(<key selector>) > .window(TumblingEventTimeWindows.of(Time.seconds(5))) > .<windowed transformation>(<window function>) > > input > .keyBy(<key selector>) > .window(TumblingEventTimeWindows.of(Time.seconds(5), Time.hours(-8))) > > .<windowed transformation>(<window function>) > > > > >
