Starting this morning, we started receiving badly formatted DTN messages where time cannot be parsed.
This is the spec. http://www.iqfeed.net/dev/api/docs/Level2UpdateSummaryMessage.cfm
The second boolean indicates that the ask is valid, but the time is clearly not. It appears to be using the milliseconds from the bid though.
There are other error types that started appearing today, but this is the most common.
Did something change? How should we handle the bad data?

Here are a few examples:

2,GTXO.PK,BKRT,0.,8.,0,100,08:12:34.053,2015-09-14,52,99:99:99.056,F,T,T,
2,OVIT.PK,ARCA,0.,5.,0,1300,08:03:45.009,2015-09-14,52,99:99:99.009,F,T,T,
2,ABOT.PK,MICA,0.,0.749,0,1000,08:38:25.058,2015-09-14,4c,99:99:99.058,F,T,T,

Good afternoon,

I am looking into this now and will report back shortly on my findings.

Tim

I've looked through the logs and the problem stopped as of 9-16. I only see bad data for the 14th and 15th. Consider the issue closed.

This problem just happened again. I got this line:

Z,GOOG,NSDQ,0.,698.9,0,3,04:49:20.059833,2016-01-14,52,99:99:99.000000,F,T,T,

This line claims that AskValid=True, but AskTime=99:99:99.000000, which is an invalid value.

I've also noticed the problem is back. Thanks for noting that it happens with NASDAQ as well.

There's a clear bug in the DTN code which produces level 2 messages where only one side is valid. The bid and ask times are swapped every single time!

Here are a few examples from last week:
Z,ACLZ.PK,NTFN,0.29,0.,2500,0,99:99:99.000,2016-01-06,52,05:32:12.031,T,F,T,
Z,ARSC.PK,CSTI,0.,0.0002,0,2900000,07:10:37.028,2016-01-06,52,99:99:99.000,F,T,T,
Z,CLWY.PK,ARCA,2.91,0.,100,0,99:99:99.000,2016-01-06,52,08:01:56.002,T,F,T,
Edited by eporter on Jan 14, 2016 at 11:24 AM

Ok, thanks for the reports, we are looking into what happened here with the server team.

Tim