Topics
Replies
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
lec0456
17 Sep 2013, 19:21
( Updated at: 21 Dec 2023, 09:20 )
I created a robot to test this and the indicator is not inheriting the timezone from the robot. In this example, the robot is starting the day at 17:00 and the indicator is starting the new day at 21:00
Here is the code:
//#reference: C:\Users\lcespedes\Documents\cAlgo\Sources\Indicators\MarketHours.algo
using System;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.Indicators;
namespace cAlgo.Robots
{
[Robot(TimeZone = TimeZones.EasternStandardTime)]
public class TimeZoneTest : Robot
{
private MarketHours markethours;
private TimeZoneInfo BrokerTimeZone;
protected override void OnStart()
{
markethours = Indicators.GetIndicator<MarketHours>();
var attribute = (RobotAttribute)typeof(TimeZoneTest).GetCustomAttributes(typeof(RobotAttribute), false)[0];
BrokerTimeZone = TimeZoneInfo.FindSystemTimeZoneById(attribute.TimeZone);
//BrokerTimeZone = TimeZoneInfo.FindSystemTimeZoneById("E. Europe Standard Time");
Print("RobotTimeZone Setting: {0}", attribute.TimeZone);
Print("RobotTimeZone Name: {0}", BrokerTimeZone.DisplayName);
Print("Offset: {0}", BrokerTimeZone.BaseUtcOffset);
Print("DST: {0}", BrokerTimeZone.SupportsDaylightSavingTime);
}
protected override void OnBar()
{
int t0 = MarketSeries.Close.Count - 1;
//** t0 results are not final because the bar has not completed
int t1 = t0 - 1;
if (t1 < 0)return;
DateTime BrokerTime = DateTime.SpecifyKind(MarketSeries.OpenTime[t0],DateTimeKind.Unspecified);
TimeZoneInfo NYTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
DateTime NYTime = TimeZoneInfo.ConvertTime(BrokerTime, BrokerTimeZone, NYTimeZone);
double NYValue = (NYTime.Hour * 100) + NYTime.Minute;
//** Day End Processes Start
if (NYValue==1700){
Print("BrokerTime: {0} , NYTime: {1}", BrokerTime, NYTime);
Print("Robot New Day****" + Server.Time.ToString("MM/dd/yyyy HH:mm") + "*****");}
if (markethours.NewYork[t1] == 1655)
{
Print(NYValue);
Print("Indicator New Day*****" + Server.Time.ToString("MM/dd/yyyy HH:mm") + "*****");
Print(Server.Time.Kind);
}
//** Day End Processes Start
}
}
}
Please let me know whats going on...
@lec0456
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
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
lec0456
15 Sep 2013, 22:51
protected override void OnStart()
{
markethours = Indicators.GetIndicator<MarketHours>();
var attribute = (IndicatorAttribute)typeof(MarketHours).GetCustomAttributes(typeof(IndicatorAttribute), false)[0];
//BrokerTimeZone = TimeZoneInfo.FindSystemTimeZoneById(attribute.TimeZone);
BrokerTimeZone = TimeZoneInfo.FindSystemTimeZoneById("E. Europe Standard Time");
Print("RobotTimeZone Setting: {0}", attribute.TimeZone);
Print("RobotTimeZone Name: {0}", BrokerTimeZone.DisplayName);
Print("Offset: {0}", BrokerTimeZone.BaseUtcOffset);
Print("DST: {0}", BrokerTimeZone.SupportsDaylightSavingTime);
}
I Inserted the above code and it shows that the attribute.TimeZone property is returning UTC no matter what the robot is set to!!!!!
@lec0456
lec0456
10 Sep 2013, 17:54
ok, I'm glad you will investigate. However, for the first behavior I described. And Time one behavior is a little hard to explain so let me go slowly.
True, a new day starts at 17:00EST or 21;00UTC or 00:00EEST. However, the robot will print out the new day as 21:00 no matter what time zone you set the robot.
So, in my opinion what seems to be happpening is that the indicator is reverting to using UTC time no matter what the robot says. And that would be consistent with the behavior of the Kind property.
@lec0456
lec0456
04 Oct 2013, 10:15
RE:
Spotware said:
That spotware version looks great! When will it be rolled out to the brokers?
@lec0456