IQFeed.CSharpApiClient

IQFeed.CSharpApiClient copied to clipboard

I've noticed that occasionally IQFeed sends back 99:99:99 as a time in a summary message, meaning they don't have the time.

The new Level1DynamicClient parses that as 00:00:00 which obviously, is midnight. At best, this is wrong, and at worst, not being able to know that IQ gave a "null" time might be dangerous.

I'm not really sure what the best fix for this would be, other than to have the Level1DynamicClient either parse times as TimeSpan?, or as I used to do, set TimeSpan to TimeSpan.MinValue.

Either way, it needs to happen in the parser, as afterwards you can't tell if it was a valid time or not.

@mrut2pac - You're probably best placed on this one?

@NichUK how is this handled in non-dynamic client? The simplest fix that comes to my mind is to add handling in FieldParser.ParseTime for 99:99:99 to return TimeSpan.MinValue. Will this work?

Umm dont know. Sounds confusing to me. Even Zero TimeSpan 00:00:00 represents midnight ?

@NichUK what does the date look like when we got 99:99:99?

@mathpaquette There is no date. BidTime, AskTime, etc. They are sent just as times. I can't find the 99:99:99 documented in the API docs, but I've seen it and I found this statement on a forum from someone from DTN. "Bid and ask times, when they are blanked out by the exchange, are sent through as 99:99:99."

@mrut2pac I used to handle it in my code by setting the returned TimeSpan to TimeSpan.MinimumValue, so I think that would work well.

Just an extra wrinkle...

I've just found some data that looks like this:

So you need to ignore milliseconds when parsing for 99:99:99

That's the current SnapQuote for JGM21 the 10 year Japanese Bond, BTW if you want to see for yourself.