time in the terminal at the championships - page 10

 
autoforex: According to my observations it is equal to the server time of the quotation, i.e. SET (for the quotation server).
Thank you! When my optimization is over (and it has to be over sometime), I'll try to check what's really going on there.
 
autoforex:
It will return the time of the current candle = CurrentTime(). This is easy to check.

yes I'm on top of it. A year ago I wrote a few functions which by three waters (can be reduced to two) determine the current GMT time for any candlestick.

The important inputs are: server timezone (indicated as deviation in hours from GMT) and winter/summer transition type (No/Europe/USA).

Just want to say that it is clearly not two strings and far from universal option.

PS

Developers are too lazy even to inform those "inputs" that I have to specify myself, while calculating duplicate and rewrite a lot of code.

The point is this.

Документация по MQL5: Дата и время / TimeCurrent
Документация по MQL5: Дата и время / TimeCurrent
  • www.mql5.com
Дата и время / TimeCurrent - Документация по MQL5
 
Yedelkin:

Your conclusion contradicts your own observations :) First, you observe that TimeCurrent()==22.00==TimeGMT(), but do not want to admit that TimeCurrent()==TimeGMT() in the tester. That is, you don't want to admit that the server time coincides with GMT in the tester.


It is, that's the whole "mishap".

If we're talking about the tester then obviously "someone believes" that all PCs are running on server time and all servers are in the GMT zone.

In this case the winter/summer transition and there can't be one.

Yedelkin:

Excellent conclusion in support of your position :) - Tester's fault :)


The fault lies not with the tester, but with those who "invented" to bind all the time (absolutely everything) to the time of quotes.

In this case neither in the tester nor in the trading environment there is no information about the zone in which the trading server is located and whether the time changes.

It seems to be very difficult to add two more parameters, say, in AccountInfoInteger and change TimeGMT behaviour in the tester (so that the result was corrected depending on the server zone)

Yedelkin:
Thanks! When my optimization is over (and it has to be over sometime), I'll try to check what's really going on there.

What happens there is simple thing, local time and GMT are "equalized" with server time and TimeGMTOffset pretends that winter/summer time switch never existed.

So at least the behaviour of two functions TimeGMTOffset and TimeGMT in the tester should be changed. IMHO

 
Interesting: If we are talking about the tester, then obviously "someone thinks" that all PCs are running at servers time, and all servers are in the GMT zone.

Good topic about the history time in the tester! Personally, I naively thought that if the server time is set as GMT+0, the quotes will be stored only in GMT+0-format. Now, we will have to check this point and adjust it for the tester reality, if necessary.

 
Yedelkin:
Good topic about the history time in the tester! Personally, I naively assumed that if the server time in the test was GMT+0, the quotes will be stored in the GMT+0 -format. Now, we will have to check this point and adjust it to the tester reality, if necessary.

I've been doing this for a year now, I can't do anything without it in my tester.

I haven't touched"local time" in the tester before, but I guess I'll have to.

In my opinion, for normal work in the tester you should specify zone and possibility of transition winter/summer (for "local" time) in parameters, and server settings take from trade environment.

I.e., ideally, according to those data that in the trading environment and time quotes to determine GMT, and then on the basis of GMT and tester parameters to determine the local time.

But the developers will not do it, because only two or three traders "need" it.

 
Interesting: What happens there is a simple thing, local time and GMT are "equated" to server time, and TimeGMTOffset pretends that winter/summer transition never existed.

I am aware of this feature. I assumed it was there, so it's been quite satisfactory so far. But if equating GMT in the tester to server time (in your terminology) leads to some kind of time jump, I will have to refine the code.

 
Interesting: .. because two or three out of all traders "need" it.
Are you always prepared to get that immortal phrase in advance too? :):):)
 
Yedelkin:
Are you always prepared to get that immortal phrase in advance too? :):):)
There are some things you'd rather do on your own (even if it's a mess using crutches) than wait for "the grace of nature"...
 
Interesting:
There are some things that are better to implement on your own (even if it's a mess using crutches) than to wait for "the grace of nature"...
Have you written to Service Desk on this particular issue? Was there an answer? If there is such a problem, it concerns not two or three people but everyone who uses the tester. )))
 
tol64:
Have you written to Service Desk about this particular issue? Has there been an answer? If there is such a problem, it's not a problem for two or three people, but for everyone who uses the tester. )))
I wrote, but apparently the stars were in the wrong sign at the time.
Reason: