quickTick has contributed to 53 posts out of 21120 total posts
(0.25%) in 3,673 days (0.01 posts per day).
20 Most recent posts:
If so, there might be a value in having a third option for LabelAtBeginning, where the label for BeginTime would be at beginning, and the label for EndTime would be at end.
Quote: I was going by your statement "If you intend to ask for a 24 hour period by using 00:00:00 and 00:00:00 as BeginTime and EndTime, and you do it for two consecutive days." In this scenario, if it is an HTT request, you would get the first second after midnight as part of both requests. HIT requests will not have this problem.Your example doesn't show an HIT request using 00:00:00 and 00:00:00 as BeginTime and EndTime. Only the example HTT request does so.
--- Original message by DTN_Gary_Stephen on Feb 16, 2023 06:22 AM
So far, I would expect two HIT requests for two consecutive days, using 00:00:00 and 00:00:00 as BeginTime and EndTime, to both include the 00:00:00 bar that is between these two days. I believe this according to the example in the documentation.
However within a single request that crosses midnight, I would not expect any problem within the middle of the request, as your example shows. I would not expect such a problem for HTT either. The bars within a single request never overlap. Or if they did, that would a bug and completely different. I don't think we have a bug here, just that the documented behavior is easy to misunderstand when deciding which labels to use for BeginTime and EndTime, if you actually want the first bar to be *after* the BeginTime label, and the last bar to be *before* the EndTime label, which is spresumably the case if you use 00:00:00 to 00:00:00 intending to get 24 hour period. Since then, depending on the value of LabelAtBeginning, both the first and the last bar will be either before, or after each midnight.
Within a single request, there is no overlap.
> A 24 hour period would be: [00:00:00 - 00:00:00), that is it starts on midnight,
> and includes everything up to but not including the next midnight (less than)
That actual implementation appears to be 'less than or equal' for the interval specification.
The following example is from the documentation, asking for the days between the 19th and the 30th. It includes both the 19th and the 30th:
So, my current understanding is this:
If you intend to ask for a 24 hour period by using 00:00:00 and 00:00:00 as BeginTime and EndTime, and you do it for two consecutive days, you actually get the 00:00:00 interval twice.
Depending on LabelAtBeginning, you get either the interval before midnight twice, or the intervall after midnight. Although each intervall begins with .000000 and ends with .999999 microsconds. Only the unspecified values are 'less than', whereas the specified interval is 'less than or equal'.
So if you are querying for minute intervals in a 24 hour period, you need to query either
00:00 to 23:59 or
00:01 to 00:00 next day, depending on LabelAtBeginning.
Although in each case, the bar before midnight ends with 23:59:59.999999 , and the bar after midnight ends with 00:00:59.999999.
Please correct if incorrect in any detail.
Edited by quickTick on Feb 14, 2023 at 02:01 PM
Edited by quickTick on Feb 14, 2023 at 02:02 PM
Edited by quickTick on Feb 14, 2023 at 02:04 PM
Edited by quickTick on Feb 14, 2023 at 02:05 PM
I think my previous message needs at least one correction:
I asked: "So that at the upper end, 10:40:00 is just a shorthand for saying 10:39:59.999999, regardless of the labelling direction?"
However I now think that at the upper end, 10:40:00 is a shorthand for 10:39:59.999999 only if the labelling is at the end.
If labelling is at the beginning, it is a shorthand for 10:40:00.999999 .
Strangely that seems to mean that at the lower end, with labelling at the end, 10:40:00 stands for 10:39:59.000000 .
So labelling at the end seems very confusing if one is interested in that detail at all.
The default now seems to be "1" for labelAtBeginning.
For that, the range for the whole day appears to be 00:00:00 to 23:59:59 .
Which will include 23:59:59.999999 .
The specification 00:00:00 to 00:00:00 (next day) would be wrong in either case.
I'm not completely clear on this comment:
"It defaults to the end, so "10:40:00" represents 10:39:59 to 10:40:00."
The meaning of the text seems to imply that more precisely, it includes only 10:39:59.000000 to 10:39:59.999999. So that at the upper end, "10:40:00" is just a shorthand for saying "10:39:59.999999", regardless of the labelling direction?
And 10:40:00.000000 is in the interval labeled "10:40:01", if the labelling is at the end ?
The point of my question is to make sure that with labelling at the end, I'd have to ask for
"00:00:01" to "24:00:00" to get the whole day. If 24 is an allowed value, otherwise I'd have to take the next days date and "00:00:00".
I'm not quite sure I'm asking this question in the best possible way. I wonder if it's more complicated. Or more simple.
Edited by quickTick on Feb 12, 2023 at 12:37 AM
Edited by quickTick on Feb 12, 2023 at 12:39 AM
In case this wasn't resolved in the meantime: I've been seeing 15 sec updates for VIX.XO
Thanks for letting me know!
It did come back quickly enough.
Edited by quickTick on Mar 1, 2021 at 07:57 PM
Edited by quickTick on Mar 1, 2021 at 07:57 PM
I had a SERVER DISCONNECTED and a gap of quotes today around 10:30 am. Was it just on my end or a general thing? It was shortly after @ESH21 went below 3800.
The second time @ESH21 went below 3800, around 16:00, quotes continued, however the "T" time signal went up to 3 seconds behind.
Edited by quickTick on Feb 26, 2021 at 03:32 PM
According to the documentation, the info about KB queued is available on the admin port, if you ask for S,CLIENTSTATS ON.
As you say, it wouldn't make much sense for it to be in the port being queued. Providing the info in the admin port assumes the admin port itself is not queued, which is in fact less likely than for other ports.
Quote: Attached is the HTT response for @NQH19.@ mac
Note that the bids do not change for 17 minutes.
--- Original message by mac on Feb 21, 2019 07:20 AM
In your text file, the bid keeps the value it first acquires at 02:01:12.834878, at the value of 7091.75.
That's about a screen down from the beginning.
Right in the next line, the bid gets crossed by both ask and trade. Perhaps that is not a coincidence that it happens so close.
Perhaps the bid gets stuck because bid and ask cross. For example, somewhere might be code like "if ask < bid", perhaps even as a safety guard, and that code causes it to get stuck at that value. If so, bid and ask probably shouldn't cross in the first place, but that might be just a delay in the delivery of one vs the other.
Just a suggestion, since I don't see that on my own screen displaying the historical tick data for NQ, as far as I can tell.
I'm not sure about which field is which, but it doesn't seem to show the beginning.
Do quotes get crossed because they are stuck, or do they get stuck because they are crossed?
A quick test: the difference between local NTP time and "T" server time indicates "T" time has a small delay in addition to half of ping roundtrip. Symbols from Chicago have another, yet small, delay on top of that, and symbols from New York a bit higher delay. As far as I can tell, nothing strange or unexpected.
There are 'T' messages giving you the server time each second. I haven't tried to use them to synch yet, however I would assume they are sent at each full second.
As of right, now, I also see the gap in the historical tick data. Or maybe that's where I saw it in the first place.
The quotes got stuck at 2707.50, trades do continue (in the historical tick data).
Today as in 2019-02-11 CST, that is.
I believe I saw it at about the same time today, for ES.
Quote: Not currently.Sounds good. Do you have an estimated time frame for 6.1 ?
In IQFeed 6.1 we plan to release a new feature that will enable you to download batches of fundamental data by exchange/security type.
--- Original message by DTN_Steve_S on Feb 8, 2019 08:51 AM
Not sure what exactly the output means, but IQConnect has a configurable timeout that determines how long it waits for a client application to connect. This timeout is quite short by default, so it is good to have the client app already trying to open a connection as you issue that command. After that, IQConnect closes automatically. As I said, I'm not sure if your output indicates this situation.
Thanks for the info!
So if I load or reload an option chain maybe 1 hour before OPRA market open, there will be no need to check for updates for the rest of the day.
Regarding the listed markets, I did a quick comparison of the current list, and the one you have on your website. It seems the listedMarketID is more stable than the shortname. For example,
ARCA changed to NYSE_ARCA, yet remained at ID 11. And NMS changed to NGM, yet remained at ID 1 (although ID 21 was added).
So does the ID remain the same as long as a listed market exists?
For security types, can we expect that types 1, 2, 6, 8 and 9 will always keep their meaning, even if others are added or removed?
Edited by quickTick on Nov 7, 2017 at 11:42 AM