TimeCurrent() returns corrupted future timestamps!
None required. Time comes from your broker. Contact them.
In a script, TimeCurrent() uses the last quote time from any symbol in Market Watch. Inside OnTick() , it uses the handled tick’s time. That distinction does not explain or validate the invalid timestamp. Documentation.
For your bar-close logic, you can detect the next bar without calculating its boundary from TimeCurrent() . In the chart symbol’s OnTick() , track iTime(_Symbol, your_timeframe, 0) and process bar 1 when the opening time advances. Establish a baseline on the first valid read, check for zero/data errors, and define how to handle missed bars after reconnection. The official OnTick example shows the basic comparison.
This detects the transition when a tick makes the new bar available, not at the exact clock boundary. It depends on valid bar data and does not repair the timestamp problem. I could not find a documented MQL5 function to force TimeCurrent() to resynchronise.
- www.mql5.com
In a script, TimeCurrent() uses the last quote time from any symbol in Market Watch. Inside OnTick() , it uses the handled tick’s time. That distinction does not explain or validate the invalid timestamp. Documentation.
For your bar-close logic, you can detect the next bar without calculating its boundary from TimeCurrent() . In the chart symbol’s OnTick() , track iTime(_Symbol, your_timeframe, 0) and process bar 1 when the opening time advances. Establish a baseline on the first valid read, check for zero/data errors, and define how to handle missed bars after reconnection. The official OnTick example shows the basic comparison.
This detects the transition when a tick makes the new bar available, not at the exact clock boundary. It depends on valid bar data and does not repair the timestamp problem. I could not find a documented MQL5 function to force TimeCurrent() to resynchronise.
Thanks, but I'm not looking for a workaround. My point is the bug itself.
The "last quote time from any symbol in Market Watch" explanation doesn't cover what's happening here. If it were just a stale or non-tick-synced value, it would still be a valid timestamp. Instead:
- (long)TimeCurrent() returns 2199093514239 (year ~69,000) and 2013211164 (year 2033) — different every run.
- Print(TimeCurrent()) itself outputs the literal string wrong datetime — the terminal refuses to format it because it's outside the valid datetime range.
- TimeTradeServer() , TimeGMT() , TimeLocal() , and iTime() are all correct and consistent.
A "last quote time" value should never leave the datetime domain. That's not a design distinction — that's corruption of the value before it reaches the script. And it reproduces on MetaQuotes-Demo, not just a third-party broker.
I'd like to know: is this a known terminal-side issue, and is anyone from MetaQuotes able to confirm what writes into the TimeCurrent() cache that can produce a value outside the valid range?
Thanks, but I'm not looking for a workaround. My point is the bug itself.
The "last quote time from any symbol in Market Watch" explanation doesn't cover what's happening here. If it were just a stale or non-tick-synced value, it would still be a valid timestamp. Instead:
- (long)TimeCurrent() returns 2199093514239 (year ~69,000) and 2013211164 (year 2033) — different every run.
- Print(TimeCurrent()) itself outputs the literal string wrong datetime — the terminal refuses to format it because it's outside the valid datetime range.
- TimeTradeServer() , TimeGMT() , TimeLocal() , and iTime() are all correct and consistent.
A "last quote time" value should never leave the datetime domain. That's not a design distinction — that's corruption of the value before it reaches the script. And it reproduces on MetaQuotes-Demo, not just a third-party broker.
I'd like to know: is this a known terminal-side issue, and is anyone from MetaQuotes able to confirm what writes into the TimeCurrent() cache that can produce a value outside the valid range?
Just run your code on MetaQuotes-Demo.
2026.10.28 11:21:35.688 __forum__ (GBPUSD,D1) As long: 1793208094
2026.10.28 11:24:03.979 __forum__ (GBPUSD,D1) iTime Bar[1]: 2026.10.27 00:00:00 (1793059200)
2026.10.28 11:24:03.979 __forum__ (GBPUSD,D1) TimeLocal : 2026.10.28 11:24:03 (1793186643)
2026.10.28 11:24:03.979 __forum__ (GBPUSD,D1) TimeGMT : 2026.10.28 15:24:03 (1793201043)
2026.10.28 11:24:03.979 __forum__ (GBPUSD,D1) TimeTradeServer: 2026.10.28 17:24:03 (1793208243)
2026.10.28 11:24:03.979 __forum__ (GBPUSD,D1) TimeCurrent : 2026.10.28 17:24:03 (1793208243)
So which server are using to get the value you reported ?
In the Strategy Tester TimeTradeServer() is always equal to TimeCurrent(), so if your values differ this isn't the tester. Outside OnTick() the value comes from any symbol in the Market Watch, so one broken symbol can corrupt it. Print the tick time of each Market Watch symbol.
A moderator corrected the formatting this time. Please format code properly in future; posts with improperly formatted code may be removed.
for(int i=0; i<SymbolsTotal(true); i++) { string sym = SymbolName(i, true); MqlTick t; if(SymbolInfoTick(sym, t)) Print(sym, " ", TimeToString(t.time, TIME_DATE|TIME_SECONDS)); }
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Problem
TimeCurrent() returns absurd future values (year 2033, even year ~69,000), while every other time source returns the correct time. Note: Print(t) itself outputs the literal string wrong datetime — the terminal refuses to format the value because it's outside the valid datetime range.
Environment
Reproduction
Output from a single run
Previous run of the same script:
Even simpler — this alone reproduces it:
Output:
Observations
Questions
Any official confirmation from MetaQuotes would be appreciated.