Wow, backtesting is all jacked up!
Wow, backtesting is all jacked up!
16 Sep 2013, 09:53
If I use UTC it uses E Europe Standard time. If I use UTC+3 its in UTC
Replies
lec0456
16 Sep 2013, 18:44
( Updated at: 21 Dec 2023, 09:20 )
So Here is whats happening. Do you see the 2 period separators? It goes from Friday sept 13th, shows activity saturday sept 14th and jumps to monday sept 16th.Notice user time is set to UTC+3.
So now I move from the backtest page to the realtime robot page. I keep the same user timezone setting of UTC+3. How many period separators do you see? One, thats the way UTC+3 is supposted to behave. It show 5 days per week not 6. So, time in backtesting is being handled differently from real-time. So, if any of your trading strategies are based on timing, backtesting is worthless...This needs to be fixed!
@lec0456
cAlgo_Development
17 Sep 2013, 12:59
We confirm that this is a bug. Will fix it ASAP.
@cAlgo_Development
Balena
19 Sep 2013, 07:37
RE:
Balena said:
so... if I start all my strategies at say 21:00:00 UTC currently...
after the bug is fixed
will I see different results?
more specifically...
I use the following to backtest...
[Robot(TimeZone = TimeZones.UTC)]
startTime = Server.Time.Date;
activeTime = startTime.AddHours(21);
stopTime = startTime.AddHours(44.9);
resetTime = startTime.AddHours(45);
so are my backtesting results not valid?
@Balena
lec0456
19 Sep 2013, 19:13
for now, If you leave everything in UTC. Robot Time, Indicator time, User Time, and don't convert anything you should be ok. The problem is that as Daylight savings is applied to different regions your calculation for starting a strategy at say 8am ny time or any specific session would have to be changed manually.
@lec0456
Balena
19 Sep 2013, 21:53
RE:
lec0456 said:
for now, If you leave everything in UTC. Robot Time, Indicator time, User Time, and don't convert anything you should be ok. The problem is that as Daylight savings is applied to different regions your calculation for starting a strategy at say 8am ny time or any specific session would have to be changed manually.
ok, everything in code is UTC... but in gui I use UTC-4 for now... so not considering Day Light Savings changes... I should be ok, right?
@Balena
Spotware
01 Oct 2013, 14:50
Yes. Version with the fix is already released for our demo build. You can download it from www.spotware.com
@Spotware
lec0456
04 Oct 2013, 10:15
RE:
Spotware said:
Yes. Version with the fix is already released for our demo build. You can download it from www.spotware.com
That spotware version looks great! When will it be rolled out to the brokers?
@lec0456
lec0456
16 Sep 2013, 10:27
Ok, correct me if I'm wrong.
It seems that when you backtest a robot set to E.Europe Time its chart is rendered in E.Europe Time. So you have to change the User time(bottom right drop down) to UTC, so there is no offset.
But that means I have to change the timezones of my indicators to UTC so they are in sync.
I don't think this is the behavior you want for backtesting. Backtesting should simulate realtime as much as posible. So the chart should render in UTC so you can apply your user time the same way as inn realtime. I mean that if I like to see my realtime charts in UTC+3, I should not have to change it for backtesting. That goes for indicators also, I should not have to set my indiccators for one timezone with realtime trading and another for backtesting.
@lec0456