The next clock change is a field

A UTC offset tells you how to read a local clock at one instant. It doesn't tell you whether that offset will still be right for an appointment next month.

In API 2.1.0, the Time API includes next_dst in the paid profile. This request asks for New York's time and next known change as of noon UTC on September 9, 2026:

GET /time/America/New_York?at=2026-09-09T12:00:00Z
X-API-Version: 2.1.0

Here is the relevant response excerpt:

{
  "timezone": "America/New_York",
  "at": "2026-09-09T08:00:00-04:00",
  "abbreviation": "EDT",
  "offset": "-04:00",
  "dst": true,
  "next_dst": {
    "at": "2026-11-01T06:00:00.000Z",
    "dst": false,
    "offset": "-05:00",
    "abbreviation": "EST"
  }
}

The fields inside next_dst describe the clock after the change. At that UTC instant, New York moves from an offset of minus four hours to minus five. A scheduling interface can show that transition before someone is surprised by it.

For the offset at a particular appointment, pass that appointment's instant in ?at=. The basic lookup also includes the offset. Don't keep using today's offset for every future date, and keep the timezone id with a recurring local schedule.

next_dst is null when the lookup finds no transition in its roughly 400-day search window. America/Phoenix is one example. Null is useful information, but it isn't a promise that the timezone's rules can never change. The field is absent when the selected profile does not include it.