Is it really that hard to figure out? Imagine an implementation that does a binary search through the characters of a file; when it lands in the middle of the line, it seeks back by one character until it finds the beginning of the line, and then compares that line to the timestamp given.

70GB will require approximately 36 binary searches to find the line you want. Assuming the lines are around 200 characters long, each binary search will require on average 100 seeks backward to find the beginning of the line. From there you can read the characters you need for the timestamp.

So your total cost is going to be 36 * (1 seek to the character, 100 seeks to the beginning of the line, a read from that offset), disregarding the almost certainly irrelevant cost of comparison to the timestamp. Note that these seeks, while still calls to seek(2), are not actual random disk seeks, because disks return blocks to the OS in 16KB chunks or so. Most of those seeks will just be a quick roundtrip through the kernel.

So you'll do, on average, 36 reads and 3636 seeks. On most modern computers, that will take maybe 100ms, which agrees with my experience in writing a similar program for some of the logfiles I work with.