Time Zone Converter Arithmetic: Fixed Offsets, Day Rollover, and the Half-Hour Bug

Converting a meeting time between zones is subtraction on offsets. The failure modes live in three details: day boundaries, half-hour zones, and summer time. Our time zone converter implements the plain arithmetic version with 12 fixed offsets, and its exact limits are worth knowing before you trust any result, ours or anyone's.

The 12 zones our converter ships

The default conversion runs from UTC at 12:00 to JST. One offset on the list is fractional: IST at plus five and a half hours. That fraction is the source of the display bug below.

The conversion, step by step

1. Compute diff = target offset minus source offset.

2. Add diff to the source hour. Keep the source minutes.

3. If the new hour is 24 or more, subtract 24 and mark the result as next day.

4. If the new hour is negative, add 24 and mark the result as previous day.

Two worked conversions

22:00 PST to JST:

1. diff = 9 - (-8) = 17.

2. 22 + 17 = 39, which is at or above 24, so 39 - 24 = 15 with a next-day marker.

3. Result: 15:00 (+1). Cross-check through UTC: 22:00 PST is 06:00 UTC the next day, which is 15:00 JST.

09:00 EST to CET:

1. diff = 1 - (-5) = 6.

2. 09 + 6 = 15, within range.

3. Result: 15:00 the same day.

The half-hour bug in our display

IST is stored as 5.5. Adding 5.5 to an hour produces a fractional hour, and the component takes the floor of the hour while leaving the minutes untouched. The 30 minutes vanish from the display.

Verified failure. 12:15 UTC to IST:

1. diff = 5.5.

2. 12 + 5.5 = 17.5.

3. The display shows the floor of 17.5, which is 17, and keeps the source minutes 15.

4. Shown result: 17:15. Correct result: 17:45.

Until the minutes handling is fixed, apply the fraction yourself. The offset difference line displays +5.5h correctly, so trust the difference, compute the target minutes by adding 30 to the source minutes, and carry into the hour when the sum reaches 60.

Fixed offsets and summer time

The US labels in the tool are standard-time offsets that never change. Real New York sits at UTC-4 during summer months, while our EST entry stays at -5 year round. CET behaves the same way: fixed at +1 while real Berlin moves to +2 in summer.

Correct any result with these rules:

1. If both locations observe summer time and both are inside their summer periods, the fixed-offset difference is still correct.

2. If both observe it and exactly one has switched, adjust the computed difference by one hour in the direction of the location that switched forward.

3. If one location never observes summer time, adjust by one hour whenever the other location is inside its summer period.

The United States and Europe switch on different dates, so rule 2 applies for a window between those dates each March and again each autumn. Look up both switch dates for the week of your meeting instead of assuming the window.

Scheduling rules that survive these limits

1. Anchor multi-zone invitations in UTC, then let each participant convert once into their own zone.

2. Convert with the tool, then verify by hand any target with a fractional offset and any date inside a summer-time switch window.

3. Write both the local time and the UTC equivalent into the invitation, in that order.

4. For recurring meetings, re-verify at each DST transition, because a slot that works in January can land outside working hours after a switch.

The overlap window matters more than the exact minute. A 9 AM New York start is 2 AM in Tokyo under standard offsets, which is a 17-hour difference, and no rounding rule fixes a meeting that only suits one side.

Honest downsides

• The tool ignores summer time entirely. Offsets are fixed constants, and results inside summer periods are wrong by one hour for zones that observe it.
• Fractional offsets lose their minutes in the display, as the 12:15 UTC to IST example shows.
• The zone list has 12 entries. Half-hour and quarter-hour zones beyond IST, and whole zones like those in parts of South America, are absent.
• One abbreviation, CST, names both US Central and China Standard Time in general use. Our list distinguishes them only by the suffix on the label.
• The day marker tells you the direction, next day or previous day, but the tool shows no calendar date.

Checklist

• [ ] Confirm the source and target offsets, including any fraction.
• [ ] Apply the day marker when the hour wraps past 24 or below 0.
• [ ] Add 30 minutes by hand for IST and any other fractional offset on our tool.
• [ ] Check both locations' summer-time status for the meeting date.
• [ ] State UTC alongside local time in every invitation.

Test your own recurring meeting through the [time zone converter](/en/time-zone-converter) at both a January and a July date. If the two results differ by an hour from what your calendar says, that gap is the summer-time rule above, and your calendar's switch dates for both zones are the data that would settle it.