Hours difference between UTC offsets

Enter a first offset and a second offset, and it subtracts the first from the second without consulting a clock, location, daylight-saving rule, or timezone database. The result is positive when the second offset is ahead of the first, negative when it is behind, and zero when both represent the same displacement from UTC. It also returns the exact difference in minutes for convenient downstream calculations.

Understand the direction of the signed result

The calculation follows one explicit order: second offset minus first offset. If offset A is UTC+02:00 and offset B is UTC+05:30, the result is +3.5 hours because B is three hours and thirty minutes farther east of UTC than A. Reversing those same inputs produces -3.5 hours. That sign is useful when a program needs to adjust a wall-clock value from the first fixed offset toward the second, but this capability deliberately does not accept or transform a date or time. It reports only the offset difference. A zero result means the two strings describe the same UTC displacement, even if one uses UTC and the other uses Z. The response includes normalized versions of both inputs, a decimal hour value, and an integer minute value. The minute value prevents ambiguity when an offset includes a half hour, quarter hour, or another valid minute component, while the hour value provides the direct answer most users need.

Enter fixed UTC offsets in a precise format

Use UTC followed by a sign, two hour digits, a colon, and two minute digits, such as UTC+05:30 or UTC-04:00. You may omit the UTC prefix and send +05:30 or -04:00. For zero, UTC and Z are accepted as concise equivalents. Whitespace around the whole string is ignored, while spaces inside the offset are rejected so malformed input cannot be silently reinterpreted. Hours must remain within the civil fixed-offset range from minus fourteen hours through plus fourteen hours. At either fourteen-hour boundary, the minute part must be 00, and every other minute part must be between 00 and 59. Requiring an explicit sign and colon keeps inputs reviewable and makes mistakes such as confusing +530 with +05:30 impossible. Returned offsets are normalized to UTC±HH:MM, so equivalent accepted forms produce a consistent machine-readable shape. Invalid values return an invalid-input error that identifies which field needs correction rather than producing a guessed result.

Know what fixed offsets can and cannot tell you

A fixed UTC offset is a numeric displacement, not a geographic timezone. This distinction matters because places can change offset with daylight-saving transitions, government decisions, or historical rules. For example, a city may use one offset in winter and another in summer, while an offset string alone contains no location or date from which to select the applicable rule. This capability therefore performs no timezone lookup and makes no claim about the current local time in a named place. That narrow scope is what makes the answer deterministic: identical strings always produce identical output, regardless of when or where the request runs. Use it for validating configuration, comparing offsets already chosen by another system, preparing schedule arithmetic when the applicable offsets are known, or testing integrations that exchange numeric offsets. If your problem starts with named zones such as Europe/London or America/New_York, resolve those zones for the relevant instant first, then pass the resulting fixed offsets here.