continue on interfacing with Python

(As mentioned before, my algo is mainly in Python (converted from Matlab..), so my questions are mainly focusing on Zorro/Python.

I tried the following simple code,
in .c, set Python vars with OHLC(and V) from the last bar, and the last bar time wdate(0) and call Python code.
This is on BarPeriod = 1 // 1-min bar

>>>
function run()
{
pySet("pO", priceOpen(0));
pySet("pH", priceHigh(0));
pySet("pL", priceLow(0));
pySet("pC", priceClose(0));
// pySet("pV", marketVol(0));
pySet("pV", 0); // FX no volume!
var wd = wdate(0);
pySet("pTf", wd);

pyX("rcode = Py2(pO,pH, pL,pC,pV, pTf)");
>>>
My question are:
1) Is the last closed bar timestamp best to use wdate(), or other better calls?
2) Some of the timestamps are not on minute edges, i.e.,
[276: Mon 19-03-25 09:58] (1.13190)
wdate = 190325 09:58:02, OHLC = [1.1319 1.1319 1.1319 1.1319]

This means, the bar closed at 9:58 is timestamped as 9:58:02 (2 sec extra?) --> I assume it's because the next tick *AFTER* 9:58 closes the 9:58 1-min bar?
If this is indeed the case I am concerned that, in after-market trading where trades might be sparse, say, between 9:57 and 9:58 there're ticks, but no ticks until 9:59:05, then the 9:58 1-min bar's 'closing time' is 9:59??

2) when the Python code gets big, it's extremely hard to debug with stand along Python (needs to write extra/complex Python drivers).
Is there a way to 'attach Python debugger(s) to the Zorro Python process for Python code debugging?

Thanks.

Normally the timestamp should be exactly 09:58:00, but historical timestamps are just read from the broker's price server, mostly from FXCM, and are not checked or corrected. Python debuggers cannot be attached, so better debug Python functions externally before calling them from Zorro. Same for R.

Thanks for the note. But this is realtime quote from IB.
I will try other broker(s) too.

Then it's not the timestamp, but the current bar end time. Are they constantly 2 seconds late or does it vary?

I've tested loading 1000 1-min real time bars on IB and FXCM.
IB is roughly 40% with either 1 or 2 secs after the minute edge, but max is 9sec! FXCM is all exactly on the minute!
Enclosed are two csv file of Python dump of each bar's OHCLV and Timestamp(unix epoch/second) from IB and FXCM.

This may reflects the poor IB data quality, but still the bar end time shouldn't be the timestamp of the tick *after* the bar edge.

wdate(0) is not a timestamp. It is the current time.

I think a bar won't end on the precise second on a normal PC and internet connection, due to background tasks. In your case, the connection to IB is obviously slower than to FXCM. If a request to IB takes 2 seconds, then the bar end is inaccurate by 2 seconds. Other processes on your PC might add to that time.

Has nothing to do with timestamps or poor data quality.

@nandv,

what are tcp connection latencies from your computer to IB and FXCM servers during data collection? Have a look at Win Resource monitor/Networking..

Hello,

I am trying usin R with Zorro in Linux with Wine and it is no posible it work trough mt4r.dll. Some solution?
best regards

This is a Python thread. You can discuss Zorro on Linux in this other established thread:
https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=474060

If wdate(0) is not, then please advise what's the right function to get the timestamp of the current bar([0]) timestamp?

Maybe we're talking past each other? A bar is a time period with a start and an end. A price quote is an event that happens at a certain time. Only price quotes have timestamps.

You can also assign a timestamp to a bar, but that is only a convention. With Zorro, it is the current time at the end of the bar. Other software might use the bar start time or middle time.

I'm working from an old memory so this may be totally wrong, but... doesn't the IB interface "batch" ticks and send them out in bursts? If so, then maybe the bursts are normally coming every 2-3 seconds?