Historically the wollongong web interface (used by GitHub-driven jobs to display job events) has displayed only the time field from the event record.
This is at times misleading; e.g., when trying to correlate timestamps in log files from the job against the event stream itself. The time you usually want in this case is actually stored in time_remote, using the agent's local clock. We should provide a first class facility for seeing both time and time_remote in a way that makes sense to the user, and which makes it clear where the timestamp came from and what value it has in determining when something happened.
In addition, we should also expose the time_factory time (see #24) and the agent monotonic delta time (#25) as well.
Historically the wollongong web interface (used by GitHub-driven jobs to display job events) has displayed only the
timefield from the event record.This is at times misleading; e.g., when trying to correlate timestamps in log files from the job against the event stream itself. The time you usually want in this case is actually stored in
time_remote, using the agent's local clock. We should provide a first class facility for seeing bothtimeandtime_remotein a way that makes sense to the user, and which makes it clear where the timestamp came from and what value it has in determining when something happened.In addition, we should also expose the
time_factorytime (see #24) and the agent monotonic delta time (#25) as well.