If you've experimented with operators and widgets described in the previous articles, you've probably noticed that some of them offer filtering options regarding time. The elements in question currently are: 

This article explains all the time settings in detail. Note that FLOW differentiates between the terms time and duration: Time is a single absolute moment, while duration is an amount of passed time, usually expressed in seconds.
​  

Trajectories of traffic objects tracked in the scene are not entirely set in stone. As the traffic object moves and the trajectory evolves, the tracker running inside the FLOW block automatically corrects previous parts of the trajectory to be more precise. Some trajectories may even be merged together. This process takes place as long as the traffic object is present in the scene. At this point, the trajectory is considered open. Only when the traffic object leaves the scene can the whole trajectory be finalized and closed.

FLOW blocks can keep a large but still only limited number of the most recent trajectories in their memory—the cache. Therefore when the cache is full and a new trajectory is created, the one with the oldest time of closure is completely deleted and therefore can't be a factor in any more calculations. That's why when you inspect past trajectories, from a certain point in time it will seem as if no trajectories existed before it. This point is different for each machine (depending on how large cache it can handle) and for each scene and time (depending on traffic density).

Among motion filters you can find the Time of occurrence filter and the similarly named Duration of occurrence filter. The difference is that the Time of occurrence filter selects trajectories that were in the scene at a specific time (or time interval), whereas the Duration of occurrence selects trajectories that were in the scene for a specific duration of time. A trajectory starts to exist with its creation and ceases to exist with its closure. Let's look at the time modes this filter offers.

The Offset and Time blocks modes also mask the selected trajectories to the set time period. This means that calculations like average speed are done only from the parts of the trajectories that satisfy the time constraints. This works similarly to the masking done by spatial filters and, just like with spatial filters, using set operators creates unions of the masks.  
​

Let's see a simple example of finding the maximum speed of an unmasked and masked trajectory. Below there are graphs showing the development of a trajectory's speed dependent on time.

Analogically, for example for the purposes of calculating the average speed of the masked trajectory, only its part that occurred between the fifth and ninth second would be used for the calculation.

Zones' and gates' time settings include only a single checkbox labeled Now. 

Widgets and REST sinks have time modes that look the same as what the Time of occurrence filter has, but with two key differences:

First, widgets and sinks don't mask trajectories—the time options are there only for the purposes of selecting the trajectories you want.

Second, when you switch to the Whole history mode, you can see a Cache-only checkbox. When it's checked, the corresponding widget or sink's output is calculated only from the trajectories that are in the cache at the time of calculation. However, some widgets and sinks calculate their results step by step—they remember their intermediate results and with each new trajectory they just update this result. An example of this can be the Statistical value widget that calculates values like maximum or average speed of selected trajectories. For the maximum speed, it only needs to remember the current maximum and compare it with the maximum speed of the currently evaluated trajectory. 

However, if you change any of the widget or sink's settings while in the non-cache-only mode, they need to recalculate their intermediate results. The previous results, which may have factored in trajectories that are no longer in the cache, will be lost. The new results will only factor in trajectories that were in the cache at the time of changing of the settings. 

You can export an excel file of the table with up to 100 pages of data. The time format you will get for the trajectories is UNIX time. How to convert UNIX time in ms format (1.1.1970) to a more understandable format? Use the following equation.

X=((A1+3600000)/86400000)+DATE (1970;1;1)

A1=Unix Time in ms that we want to convert +3600000 (number of ms in one hour), this is included to add one hour – FLOW by default shows a different time - your PC´s time. This is not the time in which the unit is installed meaning the widget data is different to the data from the export.

The excel export gives you a UTC time format. To get the correct format you need to account for this and use: 3600000x(difference in the number of hours) and based on the time zone either add or subtract these hours from the exported time value.

For time zone +2 we would add 3600000x2 = +7200000. The goal of this is to adjust the time from my PC´s timezone to the timezone of the unit.

(1970;1;1) is UNIX time, time which serves as an anchor point for time-based data to which we add the value we get by diving A1+time zone adjustment by 86400000 which is number of ms in one day.

You should also set your cell format to hh:mm:ss for the English version of the excel to see the result in the correct format. For example, by converting 1605250440905 we will get the following date - 13.11.2020. 07:54:01.

Check out how to receive FLOW's data in your own application in the introduction to FLOW's API for third parties.