Flatpeak is timezone-aware by design. All API time handling is based on UTC internally. System-generated timestamps are always returned in UTC. However, the API accepts datetime inputs in any timezone and will respond in the same timezone.

​
Use RFC3339 format

All requests must use RFC 3339 timestamps for start_time and end_time. You can send:
  • Zulu (UTC) format: 2025-06-15T00:00:00Z
  • Offset format: 2025-06-15T00:00:00+10:00
These represent different moments in time. Examples:
  • 2025-06-15T00:00:00Z → UTC
  • 2025-06-15T00:00:00+10:00 → UTC+10

​
Integration Strategy: Choose One Approach

Before integrating, choose a consistent approach to time handling:
  • UTC-first: Send and process all timestamps in UTC. Convert to local time in your system if needed.
  • Local-first: Always include the correct local timezone offset in API requests.

​
Example

Requesting raw tariff rates in UTC vs Local Time for a location in Sydney, Australia 
curl --request GET \
  --header 'Authorization: Bearer <token>'
  --url 'https://api.flatpeak.com/tariffs/rates/loc_65e42ce4d3b813479b252160
  ?direction=IMPORT
  &start_time=2025-09-15T10:00:00Z
  &end_time=2025-09-16T10:00:00Z'

​
Handling Daylight Saving Time (DST)

If you are using offsets and your request crosses DST transitions, ensure that both start_time and end_time reflect the correct time offset for the location. If different time offsets are specified, end_time takes precedence. The valid_from and valid_to times in the response will use the end_time offset. 
{
  request: {
    start_time: "2025-03-30T00:00:00+01:00",
    end_time: "2025-03-30T04:00:00+02:00",
  },
}
The example above shows how Flatpeak aligns the returned intervals to the end_time offset.