Diagnosing Naive and Time-Zone-Aware Datetime Mismatches in Backtests

Summary

The post reports a backtest failure caused by subtracting a time-zone-naive datetime from a time-zone-aware datetime while checking whether orders have timed out. The strategy had loaded historical bars and begun replay, but halted when its timeout check compared the current bar time with a stored order time. The resulting statistics show no trades because replay stopped at the exception; they do not measure strategy performance.

The author asks how timestamps should be handled and shares a proposed change that passes the bar timestamp into the timeout function instead of calling the system clock. That can make the check use market-data time, which is often more appropriate in a backtest, but it does not by itself resolve the reported exception: both timestamps must also use compatible timezone awareness and, ideally, a consistent timezone. The discussion contains no community answer or confirmed fix, so the code suggestion remains unverified. The key lesson is to inspect and normalize datetime values at both the order-time recording and comparison points.

Key ideas

• The backtest fails because the timeout comparison mixes naive and timezone-aware datetime values.
• Passing the current bar timestamp into the timeout check aligns timeout logic with simulated market time.
• The proposed parameter change alone does not guarantee compatible timezone handling.
• Stored order timestamps and bar timestamps should be normalized consistently before subtraction.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.