The next clock change is a field
next_dst gives the next known clock change and the offset after it, so scheduling interfaces can show when local time will change.
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 timezone response includes next_dst so you can see the next known change. For GET /timezone/America/New_York?at=2026-09-09T12:00:00Z, it returns:
{
"timezone": "America/New_York",
"name": "Eastern Time",
"abbreviation": "EDT",
"offset": "-04:00",
"offset_minutes": -240,
"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=. 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.