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
Found a discrepancy in TimeToString versus TimeToStruct.
In essence, there is a cutoff between normal date values and milliseconds date values, which is at: 3001.01.01 07:59:59.
The function TimeToString obeys this correctly, but the function StimeToStruct cuts off one second early, and throws a _LastError 4010: ERR_INVALID_DATETIME
Additionally, I would expect, if TimeToStruct is raising an error, TimeToString should as well, for consistency.
Code to reproduce:
Result of this script:
EDIT: I just noticed, parameters are being read in reverse on function calls, so the last _LastError print-out is actually from the code-line above. - TimeToString returns actually the correct error code, 4010 == ERR_INVALID_DATETIME.
Values range from 1 January, 1970 to 31 December, 3000. https://www.mql5.com/en/docs/basis/types/integer/datetime
Hi Amrali,
not sure about that, as milliseconds cutoff is defined as value: 3001.01.01 07:59:59.
And it seems, mql is using system fuctions and they behave exactly to this convention.
At least as far as I could deduct from this converter:
https://www.epochconverter.com/
Found a casting bug:
Reference is documentation:
https://www.mql5.com/en/docs/basis/types/casting
Failing code example:
Compiler log:
There were too strict checks for casting. From the next build, you will be able to cast NULL to simple types.
Thank you
There were too strict checks for casting. From the next build, you will be able to cast NULL to simple types.
Thank you
That is an invalid datetime. The maximum is 31 December, 3000. Datetime Type - Integer Types - Data Types - Language Basics - MQL4 Reference
Yeah, I get that, and I can adapt to the value. But shouldnt then the error be reported also when datetime values are not within the defined range? - So both functions actually dont report the error-state correctly then.
There is something to fix for sure.
2025.10.10 12:17:52.569 Script (EURUSD,H1) 3000.01.01 07:59:58 / 3001.01.01 07:59:58;
There is something to fix for sure.
2025.10.10 12:17:52.569 Script (EURUSD,H1) 3000.01.01 07:59:58 / 3001.01.01 07:59:58;
A more comprehensive test on the error reporting:
Producing following output:
I have noticed, most of the time CopyTicks is not initiating download of tick-data, though its hard to reproduce this with code other than: