This is essentially what will be possible now, with a 'CHANGE' event if the underlying clock suddenly warps/jumps to a new point in time. Your code has to be "t

This is essentially what will be possible now, with a 'CHANGE' event if the underlying clock suddenly warps/jumps to a new point in time. Your code has to be "time warp safe" in that it needs to handle this. Interestingly, most Erlang code will be because most systems will just call erlang:monotonic_time(), leaving the other calls for time-affected applications, which are rarely that many.