Sometimes, it is interesting to know the timespan a recording file covers, for example, to determine if the amount of data written per second is reasonable or to verify that data was recorded when a problem occurred.

Since the end time of one recording should correspond to the start time of the next, this information can also be used to stitch together chunks into a timeline from a set of files.

Today, a user can read events from a recording file and look at the event end time to see when they were committed, but this is not exact. The user may (incorrectly) also look at the start time of an event, which can occur hours earlier before the chunk started.

The RecordingFile class currently has the methods readEvent() and readEventTypes(), both of which throw IOException. The purpose of using readXXX() instead of getXXX() is to indicate to the user that these operations are expensive and may fail if the file is corrupt.

If we want to follow this pattern, the following methods could be added:

Instant readStartTime();
Instant readEndTime();

An alternative would be to use getStartTime() and getEndTime(). The first method is essentially free and does not throw exceptions, since the header must be read when a RecordingFile is constructed. To find the end time, we must jump from chunk to chunk to locate the last one, which takes more time and may fail.

If we were to implement "true streaming" in the future, that is, never updating the header after a chunk/segment is complete, the parser would need to jump from segment to segment (instead of chunk to chunk) to find the end time, which would be slower.