Add human-readable display for ITCH and OUCH timestamps

[chutzimir]

The timestamps in the ITCH and OUCH protocols are not human readable and showing them in a human readable manner would be very helpful, even though it may not be trivial or feasible. In case you can consider it, the way they work is:

The OUCH timestamp field gives the number of nanoseconds past midnight of the calendar date. The calendar date could reasonably safely be assumed to match the timestamp of the captured packet, with a few caveats:

• The OUCH timestamp is generated at the exchange timezone. Therefore the date of the captured packet should be calculated as if in GMT+9 (Asia/Tokyo timezone, no DST) for JNX for example.
• In August JNX will extend the night session hours so it starts at 16:30 and ends at 06:00 on the next day. The assumption of "the date is the same as the captured packet" may not be true around midnight, depending on where the packet is captured.

The ITCH timestamp for Nasdaq ITCH 5.0 seems to follow the same logic as the OUCH timestamp.

The ITCH timestamp for JNX, and ITCH 4.x for Nasdaq is trickier as it is published over two messages:

• A "timestamp - seconds" field in the "timestamp - seconds" message announces the number of seconds since midnight. Unlike OUCH, this is the number of seconds since midnight of the day the session started. E.g., after the JNX night extension, a timestamp message published at 03:00 would have the value of 97200, i.e., (24+3)*3600 seconds since midnight.
• A "timestamp - nanoseconds" field specifies the number of nanoseconds since the last seen "timestamp - seconds" message.

It would be extra useful to have a generated offset field that shows the delay between the capture timestamp and the timestamp published in the message.

[Open-Markets-Initiative]

Our generation platform has started to systematically handle timestamp formatting (see Coinbase dissectors). I was thinking about adding the Itch timestamps but time is a limited resource. Let me think about it.

[Open-Markets-Initiative]

Source generation can handle this, and I think we will add this in the future. I am closing this ticket since our priority list wont allow for this till summer or so.