Add minutes to a datetime

Supply a complete ISO datetime with either Z or a numeric timezone offset, plus a positive, negative, or zero whole-minute amount. The calculator validates the calendar and offset, converts the stated instant to UTC, performs deterministic arithmetic, and returns a canonical UTC datetime. It never reads the current time, guesses a timezone, uses network data, or depends on the machine where it runs.

Provide a complete and unambiguous starting instant

Enter the starting value as an ISO datetime containing a calendar date, a T separator, hours, minutes, seconds, and an explicit timezone designator. A value ending in Z already describes UTC. A value ending in an offset such as +02:00 or -05:30 describes local clock fields together with their exact displacement from UTC. Requiring that suffix prevents a common source of scheduling defects: a bare local time whose meaning changes according to the computer, browser, or server that parses it. The calendar portion is checked using Gregorian leap-year and month-length rules, so impossible dates are rejected instead of being silently normalized. Hours must stay within 00 through 23, while minutes and seconds must stay within 00 through 59. Optional fractional seconds may contain one to three digits and are preserved as part of the instant. The capability does not accept timezone names such as Europe/London because those require historical rule data and can introduce daylight-saving ambiguity. Use an offset that explicitly identifies the intended instant instead.

Understand how minute addition and UTC conversion work

The operation first interprets the supplied date, clock time, and numeric offset as one absolute instant. It converts that instant to UTC with calendar arithmetic, then adds the requested signed count of whole minutes. Positive numbers move forward, negative numbers move backward, and zero performs only UTC normalization. Carrying works across every boundary: an addition can enter the next hour, day, month, leap day, year, or century, while subtraction can cross the same boundaries in reverse. The result always ends in Z, making its timezone explicit and consistent for storage or comparison. Seconds and fractional seconds do not change because the offset being added is an exact multiple of one minute. The implementation does not call the JavaScript Date constructor or inspect a system clock. Instead, it counts Gregorian days, applies offset and minute arithmetic as integers, and reconstructs the UTC calendar fields. That makes the same input produce the same output in a browser, worker, automated test, or server regardless of locale and host timezone.

Use the result safely in automation and testing

This capability fits workflows that already know their starting instant and need a reproducible derived timestamp. For example, create a reminder thirty minutes after an event, calculate a fixed grace-period deadline, shift imported records from their stated offsets into UTC, or build fixtures around midnight and leap-day boundaries. The returned object includes the original trimmed datetime, the normalized integer minute amount, the shifted result, and an explicit UTC timezone label. Store or compare the result field when another system expects a canonical timestamp. Keep in mind that this is elapsed-minute arithmetic, not civil scheduling by a named region. Adding sixty minutes always adds exactly 3,600 seconds; it does not consult daylight-saving transitions or business calendars. If a human appointment must remain at the same wall-clock time after a regional offset change, resolve that region and intended offset before calling this capability. Invalid or incomplete input returns a typed invalid-input error, allowing an integration to correct the request without treating it as an infrastructure failure. API execution costs $0.002 per item, while the browser path uses the same pure calculation.