Currently, CenturionMode handles the events as one big list. This works fine, but as soon as you start to skip to a certain point in time, things start to fall apart: for each event, we only have a start time, but not a (derived) end time. This makes it very difficult to determine which events should be "active" at which point in time and it scales terribly. An example here is the discoball integration, because it is not possible to see whether the disco ball should be enabled and until what timestamp. Furthermore, the method that handles the event execution is getting too big and too complex.

Therefore, it is a good idea to refactor this to a command design pattern, where each class is responsible for its own execution. We can also give each class a time window in which it should be active, so skipping becomes much easier.