I've switched to using the timestamps in the feed as opposed to local timestamps.
But I'm now getting out of order times. My algorithm is as follows...

* If the "Message Contents" contains "C" use the last trade time.
* else if the "Message Contents" contains "b" use the bid time.
* else if the "Message Contents" contains "a" use the ask time.

This seems straight forward, but is obviously incorrect.
Could I receive a "Message Contents" with a "C" where the Bid or Ask time is after the trade time?
...or an "Message Contents" with a "b" but the ask time is greater than the bid time?

How should I use the "Message Contents" in general to figure out what timestamp to assign a quote?

Ok, 2 assumptions up front, if either of these is not true, just let me know.
You are using "Last Trade Time" and not "Most Recent Trade Time"
You are only comparing messages of a single symbol.

Assuming both of those things, the logic you are using makes sense to me. Can you just send me an example and I will take a look? If you could include which protocol you are using and what your field order is that would certainly help.

Tim

Hi Tim,

1) I'm using "Last Time"
2) Yep, only one symbol.

Today I've logged the L1 data, so I'll be comparing what I've recorded.
Please let me know if 1) is correct.

OK, here is an example: My field set is Symbol,Last,Bid,Ask,Most Recent Trade Size,Message Contents,Most Recent Trade Market Center,Bid Size,Ask Size,Last Time,Bid Time,Ask Time. The symbol is SPY.

Here is my recorded data:
27 2017-09-21 09:30:00.559 249.9000 249.89 249.90 12100 3000 100 25 FALSE
28 2017-09-21 09:30:00.559 249.9000 249.89 249.90 12100 1000 100 25 FALSE
29 2017-09-21 09:30:00.559 249.9000 249.89 249.91 12100 1100 100 25 FALSE
30 2017-09-21 09:30:00.559 249.9000 249.89 249.90 12100 100 100 25 FALSE
31 2017-09-21 09:30:00.559 249.9000 249.89 249.90 12700 100 100 25 FALSE
32 2017-09-21 09:30:00.559 249.9000 249.89 249.90 13200 100 100 25 FALSE
33 2017-09-21 09:30:00.559 249.9000 249.89 249.90 17100 100 100 25 FALSE
34 2017-09-21 09:30:00.565 249.9000 249.89 249.90 13200 100 100 25 FALSE
35 2017-09-21 09:30:00.565 249.9000 249.89 249.90 13100 100 100 25 FALSE
36 2017-09-21 09:30:00.565 249.9000 249.89 249.90 10500 100 100 25 FALSE

---> Timestamp jumps back.

37 2017-09-21 09:30:00.556 249.8975 249.89 249.90 10500 100 100 19 TRUE
38 2017-09-21 09:30:00.559 249.8800 249.89 249.90 10500 100 500 11 TRUE
39 2017-09-21 09:30:00.559 249.8950 249.89 249.90 10500 100 200 11 TRUE

Now the L1 data from IQFeed.

Q,SPY,249.9000,249.8900,249.9000,100,ba,25,12100,3000,09:30:00.545301,09:30:00.559047,09:30:00.559047,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,12100,1000,09:30:00.545301,09:30:00.559077,09:30:00.559077,
Q,SPY,249.9000,249.8900,249.9100,100,ba,25,12100,1100,09:30:00.545301,09:30:00.559107,09:30:00.559107,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,12100,100,09:30:00.545301,09:30:00.559261,09:30:00.559261,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,12700,100,09:30:00.545301,09:30:00.559797,09:30:00.559797,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,13200,100,09:30:00.545301,09:30:00.559954,09:30:00.559954,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,17100,100,09:30:00.545301,09:30:00.560185,09:30:00.560185,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,13200,100,09:30:00.545301,09:30:00.566021,09:30:00.566021,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,13100,100,09:30:00.545301,09:30:00.566318,09:30:00.566318,
Q,SPY,249.9000,249.8900,249.9000,100,ba,25,10500,100,09:30:00.545301,09:30:00.566496,09:30:00.566496,
Q,SPY,249.8975,249.8900,249.9000,100,C,19,10500,100,09:30:00.556657,09:30:00.566496,09:30:00.566496,

--> Here is the trade, note trade time 09:30:00.556657 is before the previous Bid/Ask update time (09:30:00.566496)

Q,SPY,249.8975,249.8900,249.9000,8,O,11,10500,100,09:30:00.556657,09:30:00.566496,09:30:00.566496,
Q,SPY,249.8800,249.8900,249.9000,500,C,11,10500,100,09:30:00.559100,09:30:00.566496,09:30:00.566496,
Q,SPY,249.8950,249.8900,249.9000,200,C,11,10500,100,09:30:00.560176,09:30:00.566496,09:30:00.566496,

Please advise.

Any updates here?

Craig, sorry for the delay in responding.

What you are showing here is expected behavior. The bid/ask quotes for these equities come from the exchange on a different feed and we merge them in-house before forwarding them to customers. Any effort to assure they are in chronological order would result in intentionally delaying at least one of the feeds while waiting for data from the other feed. Instead, we opt for the option that gets data to customers as quickly as possible. As a result, you will occasionally see discrepancies between trades timestamps and bid/ask timestamps in this scenario.

Thank you Steve, when you say 'different feed', do you mean different exchanges?
If this is the case should the time-stamps be chronological by market center?

This is a followup on Craig's comment about using time as follows

* If the "Message Contents" contains "C" use the last trade time.
* else if the "Message Contents" contains "b" use the bid time.
* else if the "Message Contents" contains "a" use the ask time.

For some options that are not highly traded, ask time has a value, but
bid time has 99:99:99

I have included a snippet below of an option. This was traded 10/5/2017.

Symbol,Last,Total Volume,Ask,Ask Size,Ask Market Center,Ask Time,Bid,Bid Size,Bid Market Center,Bid Time,Message Contents,Most Recent Trade Size,Most Recent Trade Market Center,Last Time

XRX1720J35 0.11 0 0.07 58 108 10:01:01.990488 99:99:99.990488 ba 2.0 13.0 10:15:24.512977
XRX1720J35 0.11 0 0.07 70 108 10:01:01.991206 99:99:99.991206 ba 2.0 13.0 10:15:24.512977
XRX1720J35 0.11 0 0.07 83 12 10:01:10.236872 99:99:99.236872 ba 2.0 13.0 10:15:24.512977
XRX1720J35 0.11 0 0.07 96 9 10:01:11.115193 99:99:99.115193 ba 2.0 13.0 10:15:24.512977
XRX1720J35 0.11 0 0.07 96 9 10:01:39.732290 0.01 15 18 10:01:39.732290 ba 2.0 13.0 10:15:24.512977

In this scenario, should the time not be that of Ask Time?

Any bid or ask update received with a 99:99:99 timestamp is the exchange saying there is no valid value currently.

Bid and ask are always sent as pairs though so you can get several invalid updates on the bid while the ask size continues to update as it does here in your example.

Tim

Thanks Tim.

So, just to double-check, it is fine to use Ask Time in my example.

Correct