Log window not showing the correct time
28 May 2024, 00:23
Why is cTrader logging a completely different time in the log (UTC time it appears since it's logging times 8 hours behind) differently from:
what cTrader's time is set to
what the computer's time is set to
when the bot itself has no time zone set
?
See screen capture below. If you ignore the fact I did a screen capture several minutes after the bot was started, you can see the timestamp in the logs is 8 hours behind the datetime set on both the computer and in the cTrader Desktop itself.
The bot doesn't specify a timezone as it just has: [Robot(AccessRights = AccessRights.FullAccess)]
You can also see that if I switch the timeframe to something like “Minute 1”, the times are shown correctly on the chart as well:
So why would it still logging the time that's 8 hours behind my time zone (UTC time) ?
It uses your cBot's timezone. If there isn't one set, it's UTC+0
Well, that's annoying. According to the way it's implemented, if I wanted any cBot to log in local time for the time zones I go through because I travel often, I would have to update, recompile, and redeploy the bot every single time I cross a timezone to update the bot instances with the timezone I'm in?
Who decided that?! O.M.G. face palm
cTrader can certainly determine if the cBot is running locally (and not in the cloud), and can also determine if there's a timezone set or not.
If I start a cBot on a VPS that's set for my local time zone running an instance of cTrader bot locally (not in the cloud) set to the current timezone I want to use, then why doesn't the bot, by default if no time zone is specified and it's running locally, use the local time zone?!
It makes more sense to use the timezone the user has selected in cTrader in than a default UTC+0.
It uses your cBot's timezone. If there isn't one set, it's UTC+0
Well, that's annoying. According to the way it's implemented, if I wanted any cBot to log in local time for the time zones I go through because I travel often, I would have to update, recompile, and redeploy the bot every single time I cross a timezone to update the bot instances with the timezone I'm in?
Who decided that?! O.M.G. face palm
cTrader can certainly determine if the cBot is running locally (and not in the cloud), and can also determine if there's a timezone set or not.
If I start a cBot on a VPS that's set for my local time zone running an instance of cTrader bot locally (not in the cloud) set to the current timezone I want to use, then why doesn't the bot, by default if no time zone is specified and it's running locally, use the local time zone?!
It makes more sense to use the timezone the user has selected in cTrader in than a default UTC+0.
This is not something that works out of the box, automatic timezone detection needs to be developed. Feel free to post a suggestion in the Suggestions and we will consider it for future releases.
It uses your cBot's timezone. If there isn't one set, it's UTC+0
Well, that's annoying. According to the way it's implemented, if I wanted any cBot to log in local time for the time zones I go through because I travel often, I would have to update, recompile, and redeploy the bot every single time I cross a timezone to update the bot instances with the timezone I'm in?
Who decided that?! O.M.G. face palm
cTrader can certainly determine if the cBot is running locally (and not in the cloud), and can also determine if there's a timezone set or not.
If I start a cBot on a VPS that's set for my local time zone running an instance of cTrader bot locally (not in the cloud) set to the current timezone I want to use, then why doesn't the bot, by default if no time zone is specified and it's running locally, use the local time zone?!
It makes more sense to use the timezone the user has selected in cTrader in than a default UTC+0.
This is not something that works out of the box, automatic timezone detection needs to be developed. Feel free to post a suggestion in the Suggestions and we will consider it for future releases.
This really shouldn't have to be a suggestion.
Seriously, who releases software so that when a user changes time zones, the user needs to recompile and redeploy their code to pick up the new time zone?
When a bot is loaded, and before it's started, cTrader should already know if a timezone is specified or not from the bot's header directive.
If there is none specified, Spotware should read the timezone the user sets in cTrader itself.
Otherwise, what's the point of having that?
Again, facepalm
I'll save Spotware's team 10 seconds with this link:
It uses your cBot's timezone. If there isn't one set, it's UTC+0
Well, that's annoying. According to the way it's implemented, if I wanted any cBot to log in local time for the time zones I go through because I travel often, I would have to update, recompile, and redeploy the bot every single time I cross a timezone to update the bot instances with the timezone I'm in?
Who decided that?! O.M.G. face palm
cTrader can certainly determine if the cBot is running locally (and not in the cloud), and can also determine if there's a timezone set or not.
If I start a cBot on a VPS that's set for my local time zone running an instance of cTrader bot locally (not in the cloud) set to the current timezone I want to use, then why doesn't the bot, by default if no time zone is specified and it's running locally, use the local time zone?!
It makes more sense to use the timezone the user has selected in cTrader in than a default UTC+0.
This is not something that works out of the box, automatic timezone detection needs to be developed. Feel free to post a suggestion in the Suggestions and we will consider it for future releases.
This really shouldn't have to be a suggestion.
Seriously, who releases software so that when a user changes time zones, the user needs to recompile and redeploy their code to pick up the new time zone?
When a bot is loaded, and before it's started, cTrader should already know if a timezone is specified or not from the bot's header directive.
If there is none specified, Spotware should read the timezone the user sets in cTrader itself.
Otherwise, what's the point of having that?
Again, facepalm
I'll save Spotware's team 10 seconds with this link:
I appreciate your contribution to the community but I cannot tolerate such language. Please respect the forum and consider this as a warning. I have developed hundreds of strategies and almost all of them need a fixed timezone regardless where the cBot is running. Decisions need to be taken at specific times no matter if the code is executed in London, New York or Beijing. Your suggestion is not as brilliant as you think. Adopting your suggestion would be devastating for many strategies. This should be an explicitly requested option in the cBot and not the default setting. However, over the last 13 years, not many people requested this, hence it was never implemented.
I have developed hundreds of strategies and almost all of them need a fixed timezone regardless where the cBot is running.
So just program in something like the following to get the time based on a fixed time zone and compare whatever actions you need that are time based agains the _Dt datetime variable instead. This has been available since .Net 3.5 I think:
Datetime _Dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(Server.TimeInUtc, "Eastern Standard Time"); //or use DateTime.Now in the API call to get the time if more appropriate
Decisions need to be taken at specific times no matter if the code is executed in London, New York or Beijing.
Then if the programmer isn't going to get time based on a specific time zone, they can have it coded in the bot to look at specific times with the C# UTC setting such as getting the time in UTC time and adding an offset. For example:
//if you know the specific time, add it to UTC
TimeSpan LocalUTCTimeSpanOffset = new TimeSpan(2, 0, 0);
DateTime _Dt = Server.TimeInUtc + LocalUTCTimeSpanOffset;
//or if the user knows what time they want things to happen in a specific time zone:
Datetime _Dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.UtcNow, "Eastern Standard Time");
//then just compare _localDt to the specific time they need things to happen
//or the user specifies the timezone in the directive tag as is currently implemented
Using the above, you have the best of both worlds – implementing the above, users can have their bots make decisions at specific times as they see fit regardless of what timezone cTrader or the server is set to and the code is running in;
when no time zone is provided in the directive and the bots are being run somewhere locally via cTrader, use the timezone the user set in cTrader so those people who travel from Spain (UTC + 2) to London (UTC + 1) to New York (UTC - 4) and back can update their cTrader setting and have the logs and other info with timestamps without having to recompile and redeploy code.
I have developed hundreds of strategies and almost all of them need a fixed timezone regardless where the cBot is running.
So just program in something like the following to get the time based on a fixed time zone and compare whatever actions you need that are time based agains the _Dt datetime variable instead. This has been available since .Net 3.5 I think:
Datetime _Dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(Server.TimeInUtc, "Eastern Standard Time"); //or use DateTime.Now in the API call to get the time if more appropriate
Decisions need to be taken at specific times no matter if the code is executed in London, New York or Beijing.
Then if the programmer isn't going to get time based on a specific time zone, they can have it coded in the bot to look at specific times with the C# UTC setting such as getting the time in UTC time and adding an offset. For example:
//if you know the specific time, add it to UTCTimeSpan LocalUTCTimeSpanOffset = new TimeSpan(2, 0, 0);DateTime _Dt = Server.TimeInUtc + LocalUTCTimeSpanOffset;//or if the user knows what time they want things to happen in a specific time zone:Datetime _Dt = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.UtcNow, "Eastern Standard Time");//then just compare _localDt to the specific time they need things to happen//or the user specifies the timezone in the directive tag as is currently implemented
Using the above, you have the best of both worlds – implementing the above, users can have their bots make decisions at specific times as they see fit regardless of what timezone cTrader or the server is set to and the code is running in;
when no time zone is provided in the directive and the bots are being run somewhere locally via cTrader, use the timezone the user set in cTrader so those people who travel from Spain (UTC + 2) to London (UTC + 1) to New York (UTC - 4) and back can update their cTrader setting and have the logs and other info with timestamps without having to recompile and redeploy code.
At the moment I don't need to do anything for 99% of cases where cBots/Indicators work in the same country. Your suggestion can be adopted for those rare cases like the ones you mention. If there is enough demand, we will consider it as a built in feature.
PanagiotisCharalampous
28 May 2024, 06:26
It uses your cBot's timezone. If there isn't one set, it's UTC+0
@PanagiotisCharalampous