Time zones and broker time

Why broker time isn't UTC, how Tickwire labels it, and how to get day boundaries right.

MetaTrader servers keep their own clock, usually UTC+2 in winter and UTC+3 in summer (“New York close” time), but not always. Tick, bar and deal times from the terminal are in that broker-local time. Treating them as UTC shifts everything by two or three hours and puts daily limits on the wrong day.

The rules we follow

• Fields named time (or ending in Time without broker) are UTC, ISO-8601 with Z.
• Fields named brokerTime are broker-local, formatted YYYY-MM-DD HH:mm:ss.SSS, with no zone suffix because they’re not UTC.
• We never put a Z on broker time.

{ "time": "2026-09-23T11:02:11.480Z", "brokerTime": "2026-09-23 14:02:11.480" }

Finding a broker’s offset

curl -s https://api.tickwire.io/users/current/accounts/acc_7Qx/server-time -H "auth-token: $TW_KEY"

{ "time": "2026-09-23T11:02:13Z", "brokerTime": "2026-09-23 14:02:13.000", "brokerUtcOffsetSeconds": 10800 }

The offset is measured: broker tick time minus UTC, rounded to 30 minutes, and only while ticks are fresh. The daylight-saving rule is worked out from the hour at which trading weeks open over several years of hourly bars. Until we’ve measured it, brokerUtcOffsetSeconds is null; we don’t fill it in with a guess.

The account snapshot (GET /users/current/accounts/{id}/snapshot) carries the same clock in its server_time section, with the offset stated explicitly as brokerUtcOffsetMinutes (null when not yet measured, never assumed to be 0).

If auto-detection gets a broker wrong, set brokerTimezone and brokerDSTSwitchTimezone on a provisioning profile.

Day boundaries for risk rules

Prop firms usually reset daily loss limits at the broker’s midnight, not UTC midnight. Use brokerTime (or UTC plus the measured offset) to decide which trading day a deal belongs to. Our risk trackers do this for you.