Dates & timezones

Distinguish the day a device experienced from the timezone used to display it.

Output timezone

The Time-Zone header controls dates formatted by the API transformer layer. This reference and its downloadable examples default to Asia/Kuala_Lumpur (UTC+8). The API itself falls back to UTC when the header is omitted:

Time-Zone: Asia/Kuala_Lumpur

Many legacy responses use YYYY-MM-DD HH:mm:ss strings rather than RFC 3339. Current tracker fields can use their provider’s own timestamp serialization. Do not parse every date field using one rigid format without checking its schema.

Calendar history

today, yesterday and calendar-date history endpoints calculate boundaries in the vehicle’s timezone. Changing the output header does not change the vehicle’s configured timezone or redefine those calendar days.

Use real calendar dates such as 2026/01/15. The existing routes check character patterns rather than calendar validity: years accept four digits including leading zeroes, and month/day patterns accept some overflowing values that Carbon may normalize. The reference describes that route syntax; it does not promise a separate 1–12 or 1–31 validation step.

Duration queries

Duration operations read start and end. The optional timezone query parameter overrides the vehicle timezone for parsing those bounds.

GET /vehicles/1001/positions/duration?start=2026-01-15%2000:00:00&end=2026-01-15%2023:59:59&timezone=Asia%2FKuala_Lumpur

This example uses an illustrative ID and dates. Replace them with your vehicle ID and the dates you need.

The hour checks use diffInHours. The duration object returned with positions and travels is serialized in UTC. Account for range boundaries and daylight-saving changes when interpreting historical data.