calgo TIME ZONE IN THE CLOUD
calgo TIME ZONE IN THE CLOUD
10 Jul 2024, 16:21
I have a question, I activated my cBot in the cloud on the cTrader platform, however, when checking the cBot's daily record/log, I found that it is recording the time without respecting the cTrader platform's time zone, that is, in the diary it is recording 3 hours more than my configured zone.
My concern is that it is not respecting my cBot algorithm that uses time to carry out operations, and with this difference between the diary and the ctrader platform configuration, it is executing operations at outdated times.
How do I synchronize the cBot time with the ctrader platform? Thanks.
Replies
firemyst
11 Jul 2024, 04:01
( Updated at: 11 Jul 2024, 06:24 )
RE: calgo TIME ZONE IN THE CLOUD
ncel01 said:
Oi thebeinvest,
This seems to be another issue (not consistent with cBots running locally).
As far as I can see this works as follows:
- Local cBot:
- Journal: Same time as defined in the UI settings.
- Log: Server time as defined in the cBot code TimeZone = TimeZones.CenAustraliaStandardTime
(UCT+0 by default, if this is not defined).- Cloud cBot information (contains both the Journal and the Log, I guess) :
- UTC+0 is shown, regardless of both the time selected in the UI settings and the TimeZone defined in the cBot code.
For me, it would make a lot more sense that all the info shown in the UI was based on the DateTime as defined in the app settings.
On the other hand, when writing to .txt files (both Journal and Log), the TimeZone as defined in the cBot code (UTC+0 if this is not defined) should be always considered. This because, unlike the info shown in the UI, the info already written into a .txt fill will remain static and will not change when modifying the current time in the app settings. The time reference should also remain static.
I'd also like to hear from Spotware some clarifications on this.
I agree with your sentiment. I recently posted about an issue where I was running cBots and noticed the logged times weren't matching up with either the specified time zone in the UI or my local computer, and was told bots only read from “cBot code TimeZone = TimeZones.CenAustraliaStandardTime”, which to me is ridiculous in itself in that every time I want/need to change time zone when traveling or running against a particular market, I have to recompile and redeploy code.
For me, it would make a lot more sense that all the info shown in the UI was based on the DateTime as defined in the app settings.
Ditto! I'm glad you and more users are saying something about this.
@firemyst
PanagiotisCharalampous
11 Jul 2024, 06:37
( Updated at: 11 Jul 2024, 06:39 )
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
@PanagiotisCharalampous
ncel01
11 Jul 2024, 06:58
( Updated at: 11 Jul 2024, 07:19 )
RE: RE: calgo TIME ZONE IN THE CLOUD
firemyst said:
ncel01 said:
Oi thebeinvest,
This seems to be another issue (not consistent with cBots running locally).
As far as I can see this works as follows:
- Local cBot:
- Journal: Same time as defined in the UI settings.
- Log: Server time as defined in the cBot code TimeZone = TimeZones.CenAustraliaStandardTime
(UCT+0 by default, if this is not defined).- Cloud cBot information (contains both the Journal and the Log, I guess) :
- UTC+0 is shown, regardless of both the time selected in the UI settings and the TimeZone defined in the cBot code.
For me, it would make a lot more sense that all the info shown in the UI was based on the DateTime as defined in the app settings.
On the other hand, when writing to .txt files (both Journal and Log), the TimeZone as defined in the cBot code (UTC+0 if this is not defined) should be always considered. This because, unlike the info shown in the UI, the info already written into a .txt fill will remain static and will not change when modifying the current time in the app settings. The time reference should also remain static.
I'd also like to hear from Spotware some clarifications on this.I agree with your sentiment. I recently posted about an issue where I was running cBots and noticed the logged times weren't matching up with either the specified time zone in the UI or my local computer, and was told bots only read from “cBot code TimeZone = TimeZones.CenAustraliaStandardTime”, which to me is ridiculous in itself in that every time I want/need to change time zone when traveling or running against a particular market, I have to recompile and redeploy code.
For me, it would make a lot more sense that all the info shown in the UI was based on the DateTime as defined in the app settings.
Ditto! I'm glad you and more users are saying something about this.
Hi firemyst,
I am also glad that we finally agree in something 😄
Regarding all the timestamps shown in the UI, it doesn't make any sense (at all), to me, that these don't match the time defined by the user.
@ncel01
ncel01
11 Jul 2024, 07:16
RE: calgo TIME ZONE IN THE CLOUD
PanagiotisCharalampous said:
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
@ncel01
PanagiotisCharalampous
11 Jul 2024, 07:59
RE: RE: calgo TIME ZONE IN THE CLOUD
ncel01 said:
PanagiotisCharalampous said:
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
Best regards,
Panagiotis
@PanagiotisCharalampous
ncel01
11 Jul 2024, 11:29
( Updated at: 11 Jul 2024, 16:00 )
RE: RE: RE: calgo TIME ZONE IN THE CLOUD
PanagiotisCharalampous said:
ncel01 said:
PanagiotisCharalampous said:
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
Best regards,Panagiotis
Panagiotis,
I don't think you have addressed any of my concerns.
cBots work on UTC time unless explicitly requested otherwise by the programmer.
I have nothing against this, nor I am putting this into question.
For execution purposes, the cBots should work on the time zone as specified in the code (UTC+0 if not defined), that will be used as Server.Time. That's clear.
However, what I am/was discussing has no impact over the cBot execution, since it has nothing to do with it. See below.
What does not make sense to me:
- Timestamps shown in the UI, do not seem to match the time defined by the user. It seems to me obvious that these should always match.
- Text files (Log & Journal): time shown in logs is not consistent with the time mentioned for the jornal. Timestamps should remain consistent across all the .txt files that are automatically generated by cTrader.
On top of this, a static reference for the time should always be used (whether this is defined by the cBot code TimeZone, or, always taken as UTC+0). Given that a .txt file will remain static and will not change when modifying the current time in the app settings, its time reference should also remain static for the sake of consistency.
I've explicitly mentioned these points in my first reply to this thread.
@ncel01
PanagiotisCharalampous
12 Jul 2024, 07:45
RE: RE: RE: RE: calgo TIME ZONE IN THE CLOUD
ncel01 said:
PanagiotisCharalampous said:
ncel01 said:
PanagiotisCharalampous said:
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
Best regards,Panagiotis
Panagiotis,
I don't think you have addressed any of my concerns.cBots work on UTC time unless explicitly requested otherwise by the programmer.I have nothing against this, nor I am putting this into question.
For execution purposes, the cBots should work on the time zone as specified in the code (UTC+0 if not defined), that will be used as Server.Time. That's clear.
However, what I am/was discussing has no impact over the cBot execution, since it has nothing to do with it. See below.What does not make sense to me:
- Timestamps shown in the UI, do not seem to match the time defined by the user. It seems to me obvious that these should always match.
- Text files (Log & Journal): time shown in logs is not consistent with the time mentioned for the jornal. Timestamps should remain consistent across all the .txt files that are automatically generated by cTrader.
On top of this, a static reference for the time should always be used (whether this is defined by the cBot code TimeZone, or, always taken as UTC+0). Given that a .txt file will remain static and will not change when modifying the current time in the app settings, its time reference should also remain static for the sake of consistency.I've explicitly mentioned these points in my first reply to this thread.
There are many complicated reasons that led to this implementation for which the explanation is beyond the scope of this work and my scope of work. As explained in another thread, I explain how cTrader works and not why it works the way it works. Nevertheless I will forward your point of view to the product team for consideration.
@PanagiotisCharalampous
ncel01
12 Jul 2024, 09:07
RE: RE: RE: RE: RE: calgo TIME ZONE IN THE CLOUD
PanagiotisCharalampous said:
ncel01 said:
PanagiotisCharalampous said:
ncel01 said:
PanagiotisCharalampous said:
Hi ncel01,
I'd also like to hear from Spotware some clarifications on this.We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
Best regards,Panagiotis
Panagiotis,
I don't think you have addressed any of my concerns.cBots work on UTC time unless explicitly requested otherwise by the programmer.I have nothing against this, nor I am putting this into question.
For execution purposes, the cBots should work on the time zone as specified in the code (UTC+0 if not defined), that will be used as Server.Time. That's clear.
However, what I am/was discussing has no impact over the cBot execution, since it has nothing to do with it. See below.What does not make sense to me:
- Timestamps shown in the UI, do not seem to match the time defined by the user. It seems to me obvious that these should always match.
- Text files (Log & Journal): time shown in logs is not consistent with the time mentioned for the jornal. Timestamps should remain consistent across all the .txt files that are automatically generated by cTrader.
On top of this, a static reference for the time should always be used (whether this is defined by the cBot code TimeZone, or, always taken as UTC+0). Given that a .txt file will remain static and will not change when modifying the current time in the app settings, its time reference should also remain static for the sake of consistency.I've explicitly mentioned these points in my first reply to this thread.
There are many complicated reasons that led to this implementation for which the explanation is beyond the scope of this work and my scope of work. As explained in another thread, I explain how cTrader works and not why it works the way it works. Nevertheless I will forward your point of view to the product team for consideration.
Panagiotis,
Noted and appreciated. Thank you!
@ncel01
ncel01
10 Jul 2024, 19:48 ( Updated at: 10 Jul 2024, 20:12 )
Oi thebeinvest,
This seems to be another issue (not consistent with cBots running locally).
As far as I can see this works as follows:
(UCT+0 by default, if this is not defined).
For me, it would make a lot more sense that all the info shown in the UI was based on the DateTime as defined in the app settings.
On the other hand, when writing to .txt files (both Journal and Log), the TimeZone as defined in the cBot code (UTC+0 if this is not defined) should be always considered. This because, unlike the info shown in the UI, the info already written into a .txt fill will remain static and will not change when modifying the current time in the app settings. The time reference should also remain static.
I'd also like to hear from Spotware some clarifications on this.
@ncel01