IntradayData omission

[Kaz2003]

The data of EUREX-futures has fallen out for 1 hour from opening.
This problem continues after the summer time change this year.
(I download these data by DesktopAPI about one year before every day.)

It has generated only in the DesktopAPI function (normally expressed as an advanced chart, and DataExport).
Where is a problem?

[Kaz2003]

Details of problem

For instance, the BUND(symbol is GBL M5-DT) futures is open to 08:00(CET). However,in GetRequestHistory(), the intraday first data is 09:00(CET).
DAX(AX M5-DT) and the DJEuroStoxx50(ET M5-DT) futures are open to 09:00(CET). However, in GetRequestHistory(), the intraday first data is 10:00(CET).
There is no data of one hour from the opening.
(AdvancedChart always displays correct data. )

This problem is generated from end of March this year, and continues for one month or more.
I need the tick data that it is the correct between these.

Does such a problem happen because my PC is Japanese Standard Time?
If so, I should change the locale of my PC?
However, I think that it is not such a problem.

This problem only seems the problem of an internal table definition of eSignal.
Please correct it promptly investigating.
If the local-file and the revision part can be taught if it only has to correct any table file, it corrects it at once for myself.

from Kaz

[DionLoy]

Hi Kaz,

Can you post the line of code that you use to call this? (ie, the line that calls GetRequestHistory)?

Thanks.

[Kaz2003]

Thanks for reply, dear DionLoy.
Yes, the code of my application is as follows.

---------------------------------------------------------------------------
.....

try{
m_hHistory = m_IHooks->GetRequestHistory(
S2B(tickerItem->m_dimeSett.m_contract.localSymbol),
S2B(tickerItem->m_barInterval),
tickerItem->m_barType,
tickerItem->m_nNumBars,
S2L("-1"),S2L("-1"));

if (m_hHistory == NULL){
AfxMessageBox("History Handle NULL",MB_OK,0);
}
else{
tickerItem->m_pHistView = m_pHistView;
tickerItem->m_hHistory = m_hHistory;
if (m_IHooks->GetIsHistoryReady(m_hHistory)){
tickerItem->OnHistData();
}
}
}
catch(_com_error& e){
.........
------------------------------------------------------------------------------------

This is accurately a copy of the part of the code.
Is it something strange in this code?

I'm downloading a lot of futures contracts specifying "2" Days and "1T" every day. ( tickerItem->m_barType = btDAYS; tickerItem->m_barInterval = _T("1T"); tickerItem->m_nNumBars = 2; )

It is quite normal in U.S. futures and Japanese futures.
The data of one hour from the opening doesn't enter German futures alone.

Thanks.

[Guest]

Are you sure this problem began to occur after daylight savings?

Have you tried to enable the "Syncronize Computer Clock", under Data->Time in the Data Manager?

[DionLoy]

Instead of passing -1 to the open and close times, could you try 0 and 1440 ? (0 mins past midnight to 1440 minutes past midnight, or 24 hrs).

[Kaz2003]

Hi, Robi. Thanks for reply.

Yes, this problem starts at the same time as the daylight savings of Europe beginning.
The downloaded tick data is written file every day.
Because it all remains, it can be confirmed whether there is correctly data at the dealings time.

Today's file is as follows.
(The line - number was added by the edit.)
No. yyyy/mm/dd HH:MM:SS
---------------------------------------------------
00001 2005/05/03 00:00:00,4240.5,1
...
05758 2005/05/03 02:59:59,4236.0,1
05759 2005/05/03 03:03:09,4235.0,94
05760 2005/05/03 03:07:18,4235.0,94
05761 2005/05/03 17:00:00,4236.5,1
05762 2005/05/03 17:00:01,4236.5,4
05763 2005/05/03 17:00:01,4236.5,1
...
26802 2005/05/04 03:05:45,4257.0,122
-----------------------------------------------------
This is the DAX futures data downloaded by the GetRequestHistory() parameter of "2days and 1T".
The trading-hour of DAX futures is 09:00--20:00(CET).
It is 16:00--03:00 at Japan standard time(in daylight savings of Europe).
It is understood that there is only data from 17:00 to 03:00 in this file above.
There is no data of one hour from 16:00 have dealings over.

By the way, the download file before and behind last year's daylight savings is presented as follows.
This is a day just before daylight savings.
--------------------------------------------------
00001 2004/03/26 00:00:00,3808.0,15
....
05355 2004/03/26 03:59:59,3849.0,3
05356 2004/03/26 04:03:35,3849.0,27
05357 2004/03/26 04:09:21,3849.0,27 <-- 03/25(Thursday) 20:00 CET close
05358 2004/03/26 17:00:15,3871.0,1594 <-- 03/26(Friday) 09:00 CET open
05359 2004/03/26 17:00:15,3871.0,0
05360 2004/03/26 17:00:15,3871.0,0
....
18464 2004/03/27 03:59:59,3833.0,15
18465 2004/03/27 04:03:26,3837.0,45
18466 2004/03/27 04:17:45,3837.0,45 <-- end of file 20:00 CET close
---------------------------------------------------
There is data of 17:00--04:00 JST, that's correct.

And, this is a day when it entered daylight savings.
---------------------------------------------------
00001 2004/03/29 16:00:31,3850.0,479 <-- 03/29(Monday) 09:00 CET open
00002 2004/03/29 16:00:31,3850.0,0
00003 2004/03/29 16:00:31,3850.0,0
....
13169 2004/03/30 03:00:00,3905.5,1
13170 2004/03/30 03:03:20,3905.0,26
13171 2004/03/30 03:08:05,3905.0,26 <-- end of file 20:00 CET close
----------------------------------------------------
There is data of 16:00--03:00 JST, that's correct.

It had been switched correctly last year.
Thus, I believe that DesktopAPI and eSignal return the data at correct dealings time of a day even if anything doesn't change the application.
However, it is not changed still like this since 27th March this year.

By the way, "Syncronize Computer Clock" of Data Manager is used as OFF.
My computer clock is synchronously adjusted by another independent program to the NTP server.
I turned ON "Syncronize Computer Clock" of Data Manager and did the download processing.
The problem was not solved. There was no change in the result. However, excluding lose the clock of about 500 milliseconds having been pointed out by another synchronous program. :-)

Data is correctly displayed in AdvancedChart at 16:00 JST though it says several times.

To tell the truth, correct data has entered 2-3 times at about the beginning of April. It was intermittent. If the Logging file is examined, it understands when it was. However, it will not be a problem when it was.
I always only operate the download program as a batch processing daily.
The result has changed into not my changing anything.
This fact thinks that the cause shows that it is mysterious on the user side.

The table is sure to be defined according to the exchange and the contracts at the trading hour of a day.
And, the cause must be in an internal table. I think that it is a table to which it refers in the place where the open time is automatically judged by point that makes the request parameter to the server or the servers end.
DesktopAPI, AdvancedChart, and there might be a difference around of that.

[Kaz2003]

Hi, DionLoy.
Thank you.
The parameters will be tried.

from Kaz

[Kaz2003]

The problem was solved.
Correct data has entered to specify 0--1440 the start end time parameter.
Thank you.
Please mend an internal table some time. If it is not so, the specification that the start end time parameter means an open close by -1 becomes a lie.
I hope for the upper compatibility to be kept.
However, it is understood that doing so strictly like that costs much.
Thank you again.

Kaz