Set your time zone
By default, all timestamps returned by the API are in UTC. This tutorial covers how to override that with the timezone parameter so timestamps come back in your preferred local time.
Overriding the default time zone
Add &timezone= to any request, using a valid IANA time zone name (for example Europe/London, America/New_York, Asia/Singapore):
https://api.sportmonks.com/v3/motorsport/fixtures
?api_token=YOUR_TOKEN&timezone=Asia/SingaporeThis converts timestamp fields such as starting_at to the specified time zone instead of returning them in UTC.
Note: this page documents the timezone parameter as it works across Sportmonks v3 APIs. If you notice any motorsport-specific endpoint behaving differently, check that specific endpoint's documentation, since some endpoints (notably live-data endpoints) treat the time zone parameter differently from standard entity endpoints.
See Timezone parameters on different endpoints for the football-API equivalent of this distinction, which is built on the same underlying mechanic.
What the time zone parameter does and does not affect
On most entity endpoints, the time zone parameter only changes how the timestamp is formatted in the response. It does not change which records are returned. A fixture starting at 00:00 UTC on a given day will still be returned by a date-based query for that UTC day, even if displaying it in your local time zone would put it on a different calendar day.
This distinction matters more for live or date-bound endpoints than for a single fixture lookup by ID. If you are building a schedule or calendar feature, account for this when matching fixtures to "today" in the user's local time zone.
Finding valid time zone values
Use standard IANA time zone identifiers, the same list used by most programming languages and operating systems (for example Europe/Amsterdam, Africa/Lagos, America/Sao_Paulo).
Common pitfalls
Passing an invalid time zone string. This returns a 400 error. Double-check the spelling and format against the IANA list, for example Asia/Singapore rather than Singapore or SGT.
Assuming the time zone changes which records match a date filter. As above, the parameter affects display formatting on most endpoints, not the underlying query, except where an endpoint explicitly documents otherwise.
Setting the time zone once and assuming it persists. The parameter is per-request. There is no server-side session state, so it must be included on every call where you want localized timestamps.
FAQ
What format are timestamps in by default? UTC, in the format YYYY-MM-DD HH:MM:SS.
Can I set a default time zone for my whole integration instead of passing it on every request? No. Add it as a constant query parameter in your own request-building code instead, so every call includes it consistently.
Related
Last updated
Was this helpful?