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.

The Time API includes deep.next_dst when you request ?deep=true, included on every plan. 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&deep=true

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,
  "deep": {
    "next_dst": {
      "at": "2026-11-01T06:00:00.000Z",
      "dst": false,
      "offset": "-05:00",
      "abbreviation": "EST"
    }
  }
}

The fields inside deep.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 offset itself doesn't require deep=true. Don't keep using today's offset for every future date, and keep the timezone id with a recurring local schedule.

deep.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. Without deep=true, the deep field is omitted rather than returning a transition value.