Developers.Time format in the MT5 terminal - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
To give it, the datetime type should become 10 bytes, and the MqlDateTime structure should be rejuvenated.
Wow, you got carried away :)
long is enough. It is 8 bytes.No one is talking about structures at all. Everything should stay as it is now.
I read the thread and realized that milliseconds are needed only for a sport interest. To be able to measure the price of a 100m run with ms accuracy.
To give it to you, datetime type should become 10 bytes, and MqlDateTime structure should become fat.
Wait for MQL6, the millisecond timer, tick history and other stuff will appear there. But I do not see the point in adding it now. IMHO.
Reading and understanding are different things.
But thanks for calculating how many bytes MqlDateTime will occupy, it will seriously affect my 12 gig, I've already seen MT5 swap.
Sereyev said what i think is clear from the beginning but i forgot what forum i am on. Milliseconds are not for synchronization with the server, but for understanding the sequence of events !
sergeev:
long is enough. 8 bytes.
Suggest further...
How to convert your long to time and extract milliseconds.
This will require additional structures, data types and a couple of three new functions to convert there and back.
Why? when there is a datetime with a ready-made wrapper.
Suggest further...
How to convert your long into time and extract milliseconds.
This would require additional structures, data types and a couple of three new functions to convert back and forth.
Why? When there's datetime with a ready-made wrapper.
Andrew, with all due respect, but you haven't thought about your answer.
Time in milliseconds is time in seconds multiplied by 1000 + the number of those very ms.
total
I take the time in milliseconds and divide it by 1000 to get our old favourite datetime with all its capabilities. PLUS the remainder of the division - the number of milliseconds.
That's it.
sergeev:
I take the time in milliseconds, divide by 1000. I get our old favourite datetime with all the possibilities. PLUS the remainder of the division is the number of milliseconds.
So, in order to know the time, I will have to divide something by something? And a rounding error? Is there any way around it without division?
So I have to divide something by something to know the time? What about rounding error? Is there any way around it without division?
but the numbers are integers :)
If you don't want to divide it, just take the last three digits, that's milliseconds.
If you don't want to divide, just take the last three digits, which are milliseconds.
How do I take them without dividing them? Convert to a string and convert the right three characters back to an integer? That doesn't inspire me.
And additional operations of getting remainder of division, multiplication and other operations to get milliseconds is some kind of savagery. IMHO. They should, for that matter, be available off-the-shelf.
I wonder not that, but why originally developers chose UNIX format to store time, and not the one we are talking about now, i.e. milliseconds?
They must know something.
Datetime type:
Тип datetime предназначен для хранения даты и времени в виде количества секунд, прошедших с 01 января 1970 года. Занимает в памяти 8 байт.
All you had to do was make it like this:
The datetime type is designed to store the date and time as the number of milliseconds elapsed since January 01, 1970. It takes up 8 bytes of memory.
What does all this division and other nonsense have to do with it? Time can be stored in any unit (even in tertes). It can be converted into any units (even terrestrial hours/seconds), even Martian ones. This will not make the amount of computational resources spent on conversion any smaller or larger. Conversion is only needed for simple understanding by Man, not by a machine.
Perhaps they decided to save money and make the compression of historical databases stronger. Dear developers, answer for the sake of history, why did they choose seconds? I think they simply considered greater accuracy unnecessary, as even now they do not understand why they need these milliseconds.
I'll come at it from the other side.
1. Bid = 1.30245 volume of 50 lots. This level lasts for 30 ms.
2. Bid = 1.30244 volume 75 lots. This level lasts for 25 ms.
3. Bid = 1.30243 volume 300 lots. It existed for 2 sec.
This information will help you in trading.
maybe for pipsizers yes ... but where is such a broker who with zero delay will enter into the market your 50 lots?
How do I take them without dividing them? Convert to a string and convert the right three characters back to an integer? That doesn't inspire me.
Have you ever wondered how datetime is converted to a structure? Not by division and remainder?
or do you think it works differently ? http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms724284%28v=vs.85%29.aspx
They should be readily available, for that matter.
bliiiiiin :) well what kind of ready-made? you were given 8 bytes - what else do you need from the developers?
The interesting thing is not that, but why the developers originally chose the UNIX format for storing time and not the one we are talking about now, i.e. milliseconds?
You seem to keep talking about some kind of time format. OK. Which ones do you know?
I personally know 3.
- 4 bytes - the number of seconds from the unix era 1970 to 2038 (INT)
- 8 byte - number of 100 nanoseconds from 1601 to 30828 (FILETIME)
- 8 byte - number of milliseconds from 1970 unix epoch to 2038 (INT64)
there is also an 8-byte time storage structure SYSTEMTIME, but it is derived. etc.
What I'm suggesting is that we give what we already have in the MT server - 8 bytes from the unix era.
what to hide? :)