A meeting at three in the afternoon in New York can land on tomorrow's calendar in Tokyo. The two dates look different, but everyone still needs to join the same call.
The Time API returns both views of that moment. In API 2.0.0, this request converts a New York clock reading to Tokyo time:
GET /time/America/New_York?to=Asia/Tokyo&at=2026-09-16T15:00
The response includes this excerpt:
{
"timezone": "America/New_York",
"at": "2026-09-16T15:00:00-04:00",
"unix": 1789585200,
"to": {
"timezone": "Asia/Tokyo",
"at": "2026-09-17T04:00:00+09:00",
"unix": 1789585200
}
}
The source and target have the same unix value because the conversion preserves the instant. Their at strings express that instant on different local clocks, complete with the date and UTC offset. These fields are in the basic response. You don't need deep=true to convert a time.
The input deserves some care. When you pass to, a timestamp without an offset is read as local time in the source zone. That's what makes 15:00 mean New York afternoon in this example. An explicit offset, including the Z for UTC, identifies the instant directly. Sending at=2026-09-16T19:00:00Z in the same conversion gives the same answer. Without to, an offsetless at is interpreted as UTC, so keep the offset when passing a timestamp you've already resolved.
For a JavaScript date, unix is measured in seconds and the numeric Date constructor takes milliseconds:
const instant = new Date(result.unix * 1000)
instant.toISOString() // "2026-09-16T19:00:00.000Z"
Don't add the returned UTC offset to that number. It already identifies the meeting's instant. Apply a timezone when displaying the date, or use the returned local at value when you want the API's representation.
There is a precision difference to keep in mind. unix is rounded down to whole seconds, while at preserves milliseconds supplied in the request. If your application needs those fractions, retain the timestamp rather than reconstructing it from integer seconds.
When a local time happens twice
On November 1, 2026, New York's clock reads 01:30 twice as daylight saving time ends. The timezone and local date are not enough to choose one occurrence. If your application needs the person to decide, ask the API to reject that ambiguity:
GET /time/America/New_York?to=UTC&at=2026-11-01T01:30&disambiguation=reject
This returns HTTP 400 with code ambiguous_time. Use earlier or later once you know which occurrence they intend, or send a timestamp with the chosen UTC offset. Retrying the same ambiguous input won't resolve it. A clock jump can also skip a local time entirely; reject then returns nonexistent_time.
Without an explicit policy, compatible is the default: it chooses the earlier occurrence of a repeated time and moves a skipped time forward by the clock jump. That may suit your application, but make the choice deliberately when accepting appointments or deadlines.
For a recurring meeting, keep its intended local time and timezone too. One resolved instant is enough for this occurrence. Resolve each later occurrence from that local schedule so a changing UTC offset doesn't move the meeting to a different hour. The Time reference covers the input and resolution options.