Moving to UTC time instead of server time
Moving to UTC time instead of server time
28 May 2013, 17:47
In the next release of cTrader and cAlgo will move to a new approach for Time. Let us compare the current solution with the new one and explain the modifications needed in the code, to ensure that your robots and indicators will continue to work correctly with the new model.
Old model
In the old model every date and time value in the platform was displayed in a Server time zone. Usually, this was a timezone where a broker's headquarters are located. The disadvantage of such schema is that the trader is usually located in a different time zone, so times and dates had to be translated to the time zone of the trader.
Another disadvantage is that robots and indicators that use dates and times (for example robots with time-filters) can behave wrong when they are transferred from one broker to another broker with different server time.
New model
In order to get rid of these disadvantages we've decided to change to a new model, so we will do the following:
- Servers of all brokers will move to UTC time and the server time will be the same for all brokers.
- Every trader will be able to use his own time offset in user interface so it will be possible to see everything in a local time zone
- All robots and indicators will work in UTC time
After the next update
After the next update all dates and times will be presented in UTC. You will be able to choose you time offset to display time in user interface.
The most important thing to do after the release is to ensure that your robots and indicators work correctly with the new approach. If a robot or indicator uses Server.Time, MarketSeries.OpenTime, position.EntryTime or pendingOrder.ExpirationTime and the logic relies on a specific server time offset it must be adjusted since these time values will be presented as UTC time.
Example
This is an example of a robot that must be updated:
My robot uses a time filter, i.e. it can trade only within the specific period of time, so I have a code like this:
protected override void OnTick()
{
var currentHour = Server.Time.TimeOfDay.TotalHours;
if (currentHour < 8 || currentHour > 18)
return;
// Trade operation here
}
This robot trades from 8:00 to 18:00 server time. Let's say my broker's server time zone is UTC+2. In fact my robot's trading hours are 6:00-16:00 UTC. So, in order to keep the existing functionality after the release I must change the condition to the following:
if (currentHour < 6 || currentHour > 16)
return;
In case these values are not specified in the code, but in the robot's parameters instead, it's not needed to change the code. You can change the parameters of every instance you have.
Trend bars
One thing that will persist after this migration will be the trend-bars aggregation period. Trend bars will be aggregated using the old server time offset. it will not affect bars of Hourly or smaller Timeframe, but for larger Timeframes it can look strange. For example if my broker's time offset was UTC+2, each daily bar in UTC time will now start from 22:00 UTC. So, if I try to access MarketSeries.OpenTime I will see a date like "27.05.2013 22:00" as a beginning of a daily bar.
In approximately one month we will migrate all trend-bar databases and aggregation algorithms to UTC time and daily bars will start from 00:00 UTC. Update: For the forex symbols daily bars will start at 17:00 New York time when Forex market is open. For all brokers this time will be the same.
Replies
lec0456
29 May 2013, 00:00
Look at the period separators going from friday to monday on this chart:
http://icmarkets.ctrader.com/c/4rW5n (the week goes from 5th to the 7th to the 8th)
With brokers using UTC it considers monday's trading hours as sunday and therefore creates a period(and a candle). This error does not happen with brokers using Cyprus time.
http://fxpro.ctrader.com/c/YrW5n (the week goes from the 5th straight to the 8th) like it should
@lec0456
cAlgo_Development
29 May 2013, 09:35
OK, we got it. Than you for this feedback. We'll discuss what to do with daily trend-bar aggregation. This decision will affect only second stage of migration, next release we will migrate to UTC time but aggregation periods will stay the same.
@cAlgo_Development
lec0456
29 May 2013, 09:59
Ok, so currently the aggregation periods are set at each individual broker baased on thier time zone setting? Thats the way it seems, because for exapmle FXpro agregates daily data correctly but IC markets has that extra day.
I hope that daily data will be aggregated the same across all brokers, it would appear to me that the only way to do that is to aggregate based on Cyprus time
@lec0456
cAlgo_Development
31 May 2013, 17:34
Is this feature already released? Can you please post a video on how to adjust time?
This feature will be released next week.
@cAlgo_Development
cAlgo_Development
03 Jun 2013, 15:46
If you move to UTC time instead of the week starting on monday it will start on Sunday @21:00 then create a new day in 2 hours. So it will look like there is 6 trading days instead of 5! This screws up volume and Daily candles because you get one day at the start of the week that is bogus.
For the forex symbols daily bars will start at 17:00 New York time when Forex market is open. For all brokers this time will be the same. So there will be five complete dailty bars.
@cAlgo_Development
lec0456
05 Jun 2013, 11:59
One thing to point out that what you are proposing is using UTC time but aggregating based on New York time. So that would be UTC +4 in the summer and UTC +5 in the winter or 21:00 UTC or 22:00 UTC. C# takes care of the the conversions and changes on specific dates using the TimeZone functionality.
I mention that because if people decide to program robots based on say 21:00UTC being the start of the day they will be off in the winter. They would need to convert to NY time first and use 17:00 to be consistent year round
@lec0456
lec0456
05 Jun 2013, 12:00
RE:
One thing to point out that what you are proposing is using UTC time but aggregating based on New York time. So that would be UTC +4 in the summer and UTC +5 in the winter or 21:00 UTC or 22:00 UTC. C# takes care of the the conversions and changes on specific dates using the TimeZone functionality.
I mention that because if people decide to program robots based on say 21:00UTC being the start of the day they will be off in the winter. They would need to convert to NY time first and use 17:00 to be consistent year round
which is fine, as long as people know
@lec0456
lec0456
06 Jun 2013, 14:07
OK, so I could see why the code is crashing based on this:
http://msdn.microsoft.com/en-us/library/bb382770.aspx
However, So now it would seem that since June 6th at 6:50 for EUR/USD OpenTime.Kind is set to UTC instead of unspecified.
My question is, lets say for a broker that was using Cyprus Time like FXpro, for the times where the DateTimeKind is "unspecified" is it using Cyprus time or UTC.
To rephrase the question, are the times shown before the change to UTC using Cypus Time and the times shown after using UTC?
@lec0456
cAlgo_Development
06 Jun 2013, 17:12
Before the update all times and dates was in broker's server time. After the update all dates and times are presented in UTC. So you should change your indicator: convert time from UTC to needed timezone, instead of converting it from your broker's (Cyprus) timezone.
@cAlgo_Development
lec0456
06 Jun 2013, 20:21
I am confused. Has the update occured already?
Are you saying that after the update the historical dates and times will be in UTC as well? So, even when backtesting, the time will be UTC
Or that the times going forward will be in UTC and the historical times will be in the old broker's timezone??
So, far I see that there are historical times that are"DateTImeKind="unspecified" and new time is DateTimeKind=Utc. So that suggests that when backtesting we will be moving between 2 time zones?
@lec0456
lec0456
06 Jun 2013, 21:25
Ok, So whats going on right now is that the update has not been applied. But the broker time has changed to reflect a difference in the Kind property. Before it was unspecified and now it is UTC but the broker time is still using Cyprus time. Which does not allow me to convert it using the convert functions because it give an exception error if the Kind is UTC and the souce time is not...
@lec0456
lec0456
06 Jun 2013, 22:23
Ok, so I got an update on the IC markets platform. But! Period separators are set to conincide with 12AM user time. And have you looked at a daily chart?
http://icmarkets.ctrader.com/c/bMh5n
There is data on Sunday the 2nd, Saturday the 1st and then no data on Friday, it jumps to thursday may 30th.
I am very concerned that this is going to make backtesting useless...hope there is a fix
@lec0456
cAlgo_Development
07 Jun 2013, 11:39
On your chart daily bars are still aggregated starting from UTC 00:00 (like IC Markets does, we have not changed aggregation rules yet), so each bar starts at 00:00 UTC. There are bars for "31 May Fr" and "2 May Su" (two-hours bar), there is no "1 May Sa" bar.
In your selected timezone (UTC-4) daily bar start time is displayed like 20:00 of previous dat, i.e "31 May Fr" is displayed as "30 May Th 20:00", "2 May Su" bar is displayed as "1 May Sa 20:00" and monday bar is displayed as "2 May Su 20:00". Since there was no "1 May Sa" bar you do not see bar that opens in "31 May Fr 20:00" in you local timezone.
@cAlgo_Development
cAlgo_Development
14 Jun 2013, 16:01
It's old server time. Now we are getting rid of server time everywhere and it will be removed soon.
@cAlgo_Development
AwarenessForex
08 Dec 2013, 07:27
So why isn't spotware allowing the broker to choose its own server time? Doesn't the broker have a choice in what time is displayed in the platform?
I actually preferred the UTC +2/3 so that all trading times start at 00:00:00 Monday and finish 23:59:59 on Friday of every week.
@AwarenessForex
lec0456
08 Dec 2013, 20:03
RE:
AwarenessForex said:
So why isn't spotware allowing the broker to choose its own server time? Doesn't the broker have a choice in what time is displayed in the platform?
I actually preferred the UTC +2/3 so that all trading times start at 00:00:00 Monday and finish 23:59:59 on Friday of every week.
Of course, you mean Cyprus time or Western European time zone. so do I. I think all was fixed. You can select the time zone you like in the gui Sever +3 and you can set the time zone for robots and indicators specifically to Western European Time Zone.
The only gap I am not certain about is that when you are looking at the gui If you select Server +3 there are certain periods of maybe a week when some time zones start daylight savings on different days. During those gaps the gui will be off because it is displaying a fixed utc+3 instead of a time zone which adjusts on the proper day +2 or +3 for example
@lec0456
mike.challis
01 Jan 2016, 19:50
RE: RE:
This post has been removed by moderator due to a violation of the EULA. Broker discussions are prohibited in cTDN.
@mike.challis
seagoonfx1
13 Jan 2016, 12:19
This post has been removed by moderator due to a violation of the EULA. Broker discussions are prohibited in cTDN.
@seagoonfx1
qureshiawais739
30 Dec 2023, 05:28
( Updated at: 30 Dec 2023, 07:09 )
Hi,
Has this feature already released? Can you please post a video on how to adjust time?
best regards
@qureshiawais739
lec0456
28 May 2013, 23:31
Are you making a Big Mistake?
I am very concerned by what you are doing!!! Do you realize that if you move to UTC time instead of the week starting on monday it will start on Sunday @21:00 then create a new day in 2 hours. So it will look like there is 6 trading days instead of 5! This screws up volume and Daily candles because you get one day at the start of the week that is bogus.
Just check one of your brokers using UTC time right now
http://icmarkets.ctrader.com/c/urW5n
Look at the tick volume for a daily chart. It shows one day with no volume and 5 normal days. This completely messes up technical analysis on your platform.
@lec0456