Timestamp tracking to coverage data

[Stranger6667]

Is your feature request related to a problem? Please describe.

I'm working on Web API fuzzing research and have been using coverage to measure how well generated tests exercise Python web applications. Since fuzzing campaigns may run for a long time, I'd love to have more visibility into the temporal aspect of coverage — basically, "when during the run was each line/branch first covered?" Or at least, when any new line/branch is covered.

Why this matters:

• Helps determine when to stop fuzzing (e.g., if coverage plateaus after 30 minutes, then running longer may have little value, or it may be time to adjust the generation strategy dynamically).
• Enables comparison of different fuzzing configurations (and fuzzers) to see which discovers new code paths faster.

Is this already supported? I've checked the DB schema and some internals, but it looks like this data isn’t currently collected (7.10.5).

Describe the solution you'd like

Capture timestamps during collection and store them in the DB, so this data can later be exported to JSON (e.g., as an array of integers, where each integer is an offset from the start time).

Describe alternatives you've considered

If the existing plugin API already supports this, I'd be happy to look there. It might also be possible to hack it by hooking into Python's tracing mechanism, collecting this data separately while still passing coverage data along.

Additional context

I realize this might have performance implications in the common case, so maybe it could be opt-in via a flag. Schema changes would likely have a small impact, but I don’t have data on that. Emitting this data in JSON could also be behind a flag.

This idea originally comes from the desire to measure improvements in Schemathesis.

Would this be something you'd consider valuable? I'm happy to take a stab at implementing it if there's interest!

[nedbat]

Thanks for the idea, but this sounds like a very niche use, and would require significant changes to the data collection. There might be something tricky we could do with either plugins or contexts, but I don't know what it would be off the top of my head.

[Stranger6667]

@nedbat Thank you for your response!

It is indeed niche, and I was thinking about the least invasive way - maybe a way to hook into the DB schema would help here? E.g., in such a hook, I can add a new table and CREATE TRIGGER on arcs / other tables to collect current_timestamp, then just manually query these extensions after all coverage is collected to avoid changing the report workflow