Building a Reliable XAUUSD Tick Pipeline with a Precious Metals API: Our Battle with Daylight Saving Time

What happens when your gold trading strategy suddenly breaks in summer

It was one of those late-night debugging sessions that every cross-border fintech startup knows too well. Our team had just rolled out an internal platform that combined a precious metals API with a custom backtesting engine for XAUUSD tick data. The system performed beautifully during the winter months. Our momentum-based intraday strategies were hitting win rates and Sharpe ratios that made our investors raise their eyebrows — in a good way.

Then, without any code changes, the models began to deteriorate. Signals that should have triggered right at the New York open were instead firing one hour late. Live simulations diverged from backtests in ways we couldn’t explain. As the founders, we were staring at a crisis of data integrity — and we needed to fix it before our track record suffered.

Unpacking the problem: when time becomes a variable

We traced every failure back to one assumption we’d made early on: that converting timestamps from the precious metals API to UTC was as simple as adding a constant offset. The API returns data in US Eastern Time. We’d hard-coded Eastern Time as “UTC minus 5 hours.” That’s true in winter. It’s false during daylight saving time.

The error is subtle but devastating at tick resolution. Here’s a concrete example:

Time Status	US Eastern	UTC
Standard Time	09:30	14:30
Daylight Saving	09:30	13:30

A tick generated during the summer at 13:31 UTC was being wrongly classified under the 14:31 UTC minute candle, which completely reshuffled the order book snapshots our strategy relied on. Our precious metals API was feeding us perfect prices — our own code was misplacing them in time.

Engineering the fix: a UTC-centric data pipeline

We rebuilt our tick ingestion pipeline around a single principle: UTC is the only timezone that exists inside the system.

Regardless of the source format, every timestamp is transformed into UTC at the earliest possible moment — before it enters the database, before it reaches the K-line aggregator, and certainly before any strategy code sees it. Python’s zoneinfo module became our trusted ally because it dynamically resolves DST transitions based on the operating system’s timezone database.

The conversion function we now use everywhere:

from datetime import datetime
from zoneinfo import ZoneInfo

time_str = "2026-06-05 09:30:00"

new_york = ZoneInfo("America/New_York")
utc = ZoneInfo("UTC")

dt = datetime.strptime(
    time_str,
    "%Y-%m-%d %H:%M:%S"
)

local_time = dt.replace(tzinfo=new_york)
utc_time = local_time.astimezone(utc)

print("UTC time:", utc_time)

For real-time data, we applied the identical logic in our WebSocket message handler. When we connected to a reliable market data provider such as AllTick for live XAUUSD ticks, the first thing on_message does is convert the timezone:

import websocket
import json
from datetime import datetime
from zoneinfo import ZoneInfo

def on_message(ws, message):
    data = json.loads(message)

    price = data.get("price")
    trade_time = data.get("tradeTime")

    eastern = ZoneInfo("America/New_York")
    utc = ZoneInfo("UTC")

    dt = datetime.strptime(
        trade_time,
        "%Y-%m-%d %H:%M:%S"
    )

    utc_time = dt.replace(
        tzinfo=eastern
    ).astimezone(utc)

    print(price, utc_time)


ws = websocket.WebSocketApp(
    "wss://api.alltick.co/ws",
    on_message=on_message
)

ws.run_forever()

From that point forward, K-line aggregation, strategy logic, and storage all operate on UTC. The rendering layer handles conversion to any display timezone.

The business impact: reclaimed time and regained trust

Before this fix, each DST transition season required two engineers to spend several days manually reviewing timestamps, correcting historical datasets, and re-running backtests. That’s a significant annual drain on a lean startup’s resources. Now, those days are fully reclaimed for feature development and alpha research.

But the larger benefit is confidence. When your precious metals API delivers tick data and your strategies consume it, you must be absolutely certain that every data point sits in the correct temporal context. We learned the hard way that a one-hour offset can be more damaging than a pricing error. Fixing it gave us a foundation we can scale on — no matter how many strategies or markets we add.