What's new in MetaTrader 4 and MQL4 - big changes on the way - page 35

 
kazakov.v:
So you created the timezone problem yourself, and now you are creating a closed space with your own "standard" of time - different from the rest of the world.

As has been stated many times here in the forum - "traders will upload their own history".

Just take your data and import it to your liking. But instead we see exactly the same expected claim "it doesn't matter how, give me the history, so I don't have to bother and think about it". That is, even here MetaQuotes is to blame.

To save traders' minds, we have created MetaTrader 5, where you just use the platform and do not even think where the detailed data is coming from, accurate to M1 over a dozen years.

 
kazakov.v:
So you created the problem with timezones yourself, and now you are creating a closed space in which you have your own "standard" of time - different from the rest of the world.
Can you elaborate on what the problem is and what kind of enclosed space?
 
I think there's a different problem, and it lies in the user's head... or his intentions.
 
Urain:
Can you elaborate on what the problem is and what kind of closure is it?
As everyone knows, the datetime variable contains the number of seconds since January 1, 1970 00:00. Obviously, this is the prototype of the unix time format. But there is a very important clarification in the original source: 00:00 is UTC time. And any computer in any timezone will produce the same time_t value at the same moment. In other words, time_t uniquely identifies a point in time. You can convert time_t to a symbolic form in different ways, depending on timezone, daylight saving time rules - in general, according to end-user's wishes. In other words, binary representation is primary. But MQ has decided that it's easier to use trading server time (symbolic) as a base. And here is what we have got: for example, now time_t == 100000, and a UTC+1 trade server signs a new bar 103600, another UTC+2 trade server signs a new bar 107200. It means that bars displaying the same period have different values in datetame field. At first glance, it looks familiar. But try to apply stats from server in USA to server in Europe - if we just move it to fixed time, then twice a year data will split, because daylight saving time occurs on different days. Some servers, for example, changed time from NET to EET - and now it's so easy without a bottle to distinguish what shifts.
 
kazakov.v:
As everybody knows, the datetime variable contains the number of seconds since January 1, 1970 at 00:00. Obviously, this is a prototype of the unix time format. But there is a very important clarification in the original source: 00:00 is UTC time. And any computer in any timezone will produce the same time_t value at the same moment. In other words, time_t uniquely identifies a point in time. You can convert time_t to a symbolic form in different ways, depending on timezone, daylight saving time rules - in general, according to end-user's wishes. In other words, binary representation is primary. But MQ has decided that it is easier to use trading server time (symbolic) as a base. And here is what we have got: for example, now time_t == 100000, and a UTC+1 trade server signs a new bar 103600, another UTC+2 trade server signs a new bar 107200. It means that bars displaying the same period have different values in datetame field. At first glance, it looks familiar. But try to apply stats from server in USA to server in Europe - if we just move it to fixed time, then twice a year data will split, because daylight saving time occurs on different days. Some servers, for example, changed time from NET to EET - and now it's so easy without a bottle to distinguish what shifts.

Yeah, that's what you mean. The question here is simple, thanks to this MQ with saved a lot of CPU time, in terms of Amazon forests practically planted it all over again.

The assumption is that the datafeed of dilling is in dilling and will die, there will be no migration of quotes from one dilling to another. In principle the assumption is correct, why would the quotes be migrated from one dealership to another.

If we don't do what MQ did (binding to the time of dealing) then at every data call they will need to convert them (make a GMT shift) to be correctly displayed to the local time. And the data is read often, and for every read call a converter would have to be put in place.

There's a philosophical question as to whether to do a local daylight saving cycle or have the whole world go to a single universal time. And MQ did not want to become a Promethean but simply followed the market. The market wants the Americans to wake up at the terminal and the Europeans want to see 8am.

Therefore, binding to the dealing is kind of logical. Moreover, MQL5 has a function for GMT translation, so expect that this function will also be implemented in mql4++.

 

Renat:

But what you said about your cup and independence is really a sunk cost, which has only put the brakes on development. And ignoring MT5 was because you didn't see the point and you already had a ready-made solution with MT4. With MT5 you would have obtained a much faster and more beautiful solution.


If you are calling our ECN a tumbler, I want to be able to quickly make the fixes that I need, not the fixes that the vast majority of companies need. I can see perfectly well that we have directly opposing interests to most other companies. Although your announcements about introducing runtime counting etc are encouraging.

If you're calling the tumblr itself a tumblr, it's been a couple of weeks' work there.

I'm not arguing that MT5 is better, I really think so myself, but I keep thinking that if I had "seen" MT5 and started with it, I would have a lot less clients now.

And after so many failures of other people's developments in Alpari, I'm very cautious, I would even say skeptical, and I don't want to entrust them with my business. I'm sure you, as a developer, should understand me.

 
Rann:


If you're calling our ECN a tumblr, I want to be able to quickly make the fixes that I need, not the fixes that the vast majority of companies need. I can see perfectly well that we have directly opposing interests to most other companies. Although your announcements about the implementation of execution time counting and so on are encouraging.

If you're referring to the tumblr itself as a tumblr, it was a couple of weeks' work.

I'm not arguing that MT5 is better, I really think so myself, but I keep thinking that if I had "figured out" MT5 and started with it, I would have far fewer clients now.

And after so many failures of other people's developments in Alpari, I'm very cautious, I would even say skeptical, and I don't want to entrust them with my business. I'm sure you, as a developer, should understand me.

That is, the real purpose of brokering is replaced by an itch to develop. I have exactly the same itch, but my itch is fully aligned with my business focus.

The betting in MT5 is fully integrated with the whole system, all the gateways, processes, experts etc. And any MT5 broker is completely free of gateway issues. If you need it, it's much easier to write the gateway using the internal and tricked-out MetaTrader 5 Gateway API. So, you don't have to waste your time on programming itch.

But some continue to criticise MT4 and don't look at MT5, where all this has been fixed at the root. And several brokers have already turned a blind eye, gone to write ECN and are now beginning to suspect something.

 
Renat:

That is, the real purpose of brokering is replaced by an itch to develop. I have exactly the same itch, but I have it fully aligned with the business direction.

The betting in MT5 is fully integrated with the whole system, all the gateways, processes, experts etc. And any MT5 broker is completely free of gateway issues. If you need it, it's much easier to write the gateway using the internal and tricked-out MetaTrader 5 Gateway API. So, you don't have to waste your time on programming itch.

But some people continue to criticize MT4 and don't look at MT5, where all this is fixed at root. And several brokers have already turned a blind eye, went to write ECN and are now starting to suspect something.


Is MT5 pitting clients against each other?
 
Rann:

Does MT5 pairs clients with each other?

We don't focus on mass-market services for nothing. Take a look at MetaTrader 5 Exchange Server.

After its release this autumn we will have to merge all custom ECNs, as all brokers will by default get in-house ECNs with full and easy integration of the mass of gateway liquidity providers, including any MT5 providers. Including full rule-based matching.

 
Renat:

We don't focus on mass-market services for nothing. Take a look at MetaTrader 5 Exchange Server.

After its release this autumn we will have to dump all custom ECNs, as all brokers will by default get in-house ECNs with full and easy integration of the mass of gateway liquidity providers, including any MT5 providers. Including full rule-based matching.


I.e. clients will be able to match each other? I'm afraid not many companies would choose such a service. The earnings from matched clients are too low, about 4 times less than what most people earn. And the larger the client base, the higher the percentage of switched clients.
Reason: