Skip to main content

Dates and time zones

The RushHour API works in UTC. It does not convert dates and times to your company's or your user's time zone — that is up to your code.

In responses​

Dates and times are ISO 8601 strings in UTC, ending in Z:

{
  "createdTime": "2026-09-14T13:45:12Z"
}
  • Some values include fractions of a second, for example 2026-09-14T13:45:12.548Z.
  • Use a date library that understands ISO 8601 and time-zone designators, rather than cutting the string apart yourself.
  • To show a time to a person, convert it from UTC to their local time zone.

In requests​

Send dates and times as ISO 8601 strings in UTC with a trailing Z, in request bodies and in query parameters alike:

2026-09-14T08:30:00Z
  • A value without a time-zone designator, such as 2026-09-14T08:30:00, is taken as UTC. Add the Z anyway so your intent is clear.
  • Don't send local times with an offset such as +03:00. Convert to UTC first.
  • URL-encode timestamps in query strings.

Asking for a calendar day​

A "day" depends on where you are: 14 September in New York starts at 2026-09-14T04:00:00Z, not at midnight UTC. When a filter takes a start and an end — for example the routes or orders for one day — send the start and end of that day in your time zone, converted to UTC:

Local day (New York, summer time)StartEnd
14 September 20262026-09-14T04:00:00.000Z2026-09-15T03:59:59.999Z

The end is the last millisecond of the day, not the last whole second: stored times can include fractions of a second, so an end of 03:59:59Z could leave out records from the final second. The Company Portal builds its range the same way when it loads one day's routes, so a request built like this matches what your team sees for that day.

Differences between endpoints​

Date filters are not all alike. Depending on the endpoint:

  • the start and end may be included in the range, or only values strictly between them may match;
  • the full time may be compared, or only the calendar date part of each value.

When exact boundaries matter — for example when you read data in consecutive date windows — make the windows overlap slightly and remove duplicates by record ID, rather than relying on exact edges.

Last updated on