Multi time frame trading

Hello, I am using BarPeriod=1 and would like to use different time frames like 1H, 4H, Daily on top of it. If I set TimeFrame to 240 for 4H Bars I get messy starting dates, as I understood TimeFrame does not guarantee alignment as it will just count 240 Bars from the start, I have tried using frameSync() without success too, could anyone tell me how could I get aligned Bars with starting dates for instance 00:00, 04:00, 08:00, etc...?
Thanks in advance.

void write(string name, int tf)
{
string Format = "n%s,%.5f,%.5f,%.5f,%.5f";

char FileName[40];

TimeFrame = frameSync(tf);

vars open = series(priceOpen());
vars high = series(priceHigh());
vars low = series(priceLow());
vars close = series(priceClose());

sprintf(FileName,name,strx(Asset,"/","")); // remove slash from forex pairs

if(is(INITRUN))
file_write(FileName,"Date,Open,High,Low,Close",0);
else if (frame(0))
file_append(FileName,strf(Format,
strdate("%Y-%m-%d %H:%M"),
open[0],
high[0],
low[0],
close[0]));

}

function run()
{
BarPeriod = 1;

StartDate = 20170103;
EndDate = 20170331;

write("History\%s_H1.csv",60);

write("History\%s_H4.csv",240);
}

When using the code above I can get the 1H Bars but instead of getting the 4H Bars with the next write function call I get weekly Bars, could anyone tell me what am I doing wrong please ?

As to my knowledge, frameSync synchronizes to a full hour, day, or week, but not to 4 hours. Although it could make sense to implement that.

Thx for your answer, I see, no problem I will find a way to customize it, however I noticed that using the code above I get hourly Bars constructed using for instance minutes Bars from 00:01 to 01:00 for the 1H Bar with date 01:00, is there a simple way of getting instead a 1H Bar with a date 1:00 but constructed from 1M Bars from 00:00 to 00:59 as if BarPeriod=60 and TimeFrame=0 ? Do I have to apply some sort of offset ?

You would then get one wrong bar in any of your time frames. Price history stores M1 ticks by their close time, not their start time. If you still want to offset bars for some reason, use the TickFix variable.

Well in my opinion it is doing so that gives a wrong Bar as building 1:00 the 1H Bar in that way we consider the 1:00 1M Bar has ended which is not the case as it will end at 1:00:59...I do not understand the logic behind as Zorro builds the 1:00 1H Bar when setting BarPeriod=60 using 1M Bars from 00:00 to 00:59 which in that case is correct in my mind.

This is interesting to me because the Ally broker API gives me the start time of the period, and I just used that for the field in my plugin, which now appears to be incorrect. So I should add BarPeriod/1440.0 to the DATE value, correct?

Expect an update from me soon.

If it's T1 data, do not add anything, because T1 has no duration. Otherwise add the duration of a tick so that the timestamp corresponds to the close price. But make sure before that Ally really returns the tick start time in their API, because this is unusual. Most prices sources use the current time at the moment when the tick was sampled.

I did not know this.

GET market/timesales:
"The datetime field will indicate the start time of an interval (for example: 09:25 will represent the interval from 09:25 to 09:30)."

I guess that Ally is an unusual broker.

And I did not implement ticks because I cannot get it to work. So that saves me a step.

From what I see in the example, the Ally datetime field looks as if it contains a start time and a duration, the 04:00. There is also a "timestamp" field. I haven't checked that in detail, but maybe the timestamp is what you need? Otherwise derive the timestamp from the datetime plus duration. Relevant is the time belonging to the "last" price of the tick.

Negative, it's just the time at which I received the history. Not very useful.

Perhaps this is a silly question, but does this also mean that D1 history would list the day after? As in, the stock market quotes would list Tuesday through Saturday?

More importantly, if a bar had not closed yet, my plugin should not be sharing data about the bar until it closes, correct? That is, the DATE value should never be in the future?

I downloaded D1 data FROM_AV twice, mid-day, and it seems to be updating the bar on the fly.

Today is October 3. Top: before. Bottom: after.

No, in D1 history there is no difference of start and end, since it has no hours. The date of the open is identical to the date of the close. This is considered by Zorro. Otherwise the calculation would be based on a wrong time, since a date literally begins at 00:00 and shifted to UTC you would get a date boundary between open and close.

As long as a bar or day is not yet closed, it must not be used for backtesting. Otherwise you would get invalid results since parameters such as the high-low range or the open-close range would be wrong.

Thank you for the clarification.