Summary: This tutorial addresses common MT5 history data export errors, focusing on MQL5 structure handling, timezone adjustments, and official documentation references.




Last week, I was building a custom backtesting module that required exporting tick data from MT5 to a CSV file. Everything worked fine on my demo account, but when I switched to a live funded account, the export function started throwing random errors. The data would export, but there were inexplicable gaps and the timestamps were completely off.

I started with the standard MQL5 approach: using the CopyTicks function to fetch data into an array of MqlTick structures. The code compiled without issues, but when I wrote the data to a file, the timestamps showed a bizarre timezone offset that didn't match either my local time or the server time displayed on the platform.

Here's where the official MQL5 documentation on Time and Date structures became my first reference point. The docs clearly state that MqlTick.time is stored in UTC. However, the hidden problem wasn't the timezone itself—it was the way the FileWrite function was handling the long integer data type for the time_msc (millisecond timestamp) field.

The error wasn't obvious at first because MT5 doesn't throw a runtime exception for data type mismatches during file writing. Instead, it silently writes garbage values. I discovered this by printing the array values directly to the Experts log before writing them to the file.

My unique insight here is that most tutorials focus on getting the data into the array but completely ignore the export formatting step. The official documentation doesn't explicitly warn that FileWrite treats long differently depending on whether you're using FILE_TXT or FILE_CSV mode. I found that using FileWriteStruct for binary exports is 100% reliable, but if you need human-readable CSV, you must explicitly convert time_msc to a string using IntegerToString before writing.

The second issue I encountered was data gaps. The EA would occasionally skip ticks during high-volatility periods. This wasn't a code problem—it was a terminal limitation. MT5's tick history is stored in a compressed format, and CopyTicks can fail if you request more data than the terminal has cached. The MQL5 Reference suggests using CopyTicks with the start and count parameters, but it doesn't mention that the flags parameter (COPY_TICKS_ALL, COPY_TICKS_TRADE, COPY_TICKS_INFO) affects the data retrieval speed differently.

After extensive testing, I settled on this workflow:

  • <strong>Request limited batches</strong>: Instead of requesting 10 million ticks at once, I loop through smaller batches of 100,000 using CopyTicks with offset tracking.

  • <strong>Explicit time conversion</strong>: Store time_msc as a string in CSV exports to prevent silent data corruption.

  • <strong>Timezone normalization</strong>: Convert UTC timestamps to your preferred timezone using TimeGMT and TimeLocal functions, then apply a manual offset based on the broker's server settings.

  • <strong>Error handling</strong>: Always check the return value of CopyTicks. If it returns -1, use GetLastError() to identify whether the issue is data unavailability or a parameter error.


    • One critical point that saved me hours: if you're exporting data for backtesting on another platform, always export in UTC and perform timezone conversion on the receiving end. This ensures your backtest aligns with the broker's candle formation times.

    Reference: MQL5 Documentation - CopyTicks Function (docs.mql5.com), MQL5 Reference - Structures and Data Types.

    This article was originally published on FXEAR.com. All rights reserved. Unauthorized reproduction is prohibited.