The timestamps from command replies are recorded when the twisted machinery gets around to it, and not when the code actually sends them.

This is not helpful for real problems, where either the async-style twisted flow or interactions between threads add inscrutable delays, and those are exactly where difficult problems come from.

One non-intrusive fix would to always log (i.e. python logging) the constructed reply as well as its dispatch. But we'd have to make sure that the construction time is used, and not the time on emit().

If we want to track above that, there is a pretty simple option: in the code which constructs the reply, grab the time and add it as a "private" keyword (oh, "__ts" or something). Then when logging, make sure to record both timestamps (and possibly a simple diff, too). The price would be to the text traffic, which will be cluttered by these new keys.