Generating events that keep time
&TIME events have the following format:
&TIME(float seconds)
The seconds parameter represents the number of seconds since the epoch, 1st January 1970. The maximum value for seconds that the correlator can accept is 1012, which equates to roughly 33658 AD, and should be enough for anyone. However, most time formatting libraries cannot produce a date for numbers anywhere near that large.
When the correlator processes an &TIME event by taking it off an input queue, the correlator sets its internal time (the current time) to the value encoded in the event. Every event that the correlator processes after an &TIME event and before the next &TIME event has the same timestamp. That is, they have the timestamp indicated by the value of the previous &TIME event. For example:
&TIME(1)
A()
B()
&TIME(2)
C()
Events A and B each have a timestamp of 1. Event C has a timestamp of 2.
If you specify the -Xclock option, and you do not send &TIME events to the correlator, it is as if time has stopped in the correlator. Every event receives the exact same timestamp. While not sending time events is not strictly incorrect, it does mean that time stands still.
You must use great care when implementing this facility. There are EPL operations that rely on correct time-keeping. For example, all timer operations rely on time progressing forwards. Timers will fail to fire if time remains at a standstill, or worse, moves backwards. There is a warning message in the correlator log if you send a time event that moves time backwards.