Time calculator

1. Start time to minutes since midnight: 9 × 60 + 15 = 555.
2. Duration to minutes: 3 × 60 + 45 = 225.
3. Add them: 555 + 225 = 780 minutes.
4. Convert back: divide by 60 for the hour, keep the remainder as minutes, and if the total is 1,440 or more, subtract 1,440 and carry a day. Here that gives 13:00.

That carry-a-day step is the part people skip when doing this in their head, and it's the part that actually matters — "3 AM" means something different depending on whether a day got carried along the way. Subtraction runs the same four steps backwards: convert both to minutes, subtract, and add 1,440 if the result is negative. For this specific 3h 45m duration, any start time at or after 8:15 PM rolls the end past midnight; anything earlier stays on the same day, as the table below shows.

Holding the 3h 45m duration fixed and changing only the start time:

Nothing here changes the length of the duration — only where it happens to fall relative to midnight changes whether the day count ticks over. Useful to glance at if you're checking a shift or a journey that starts late at night, before assuming the finish is still "today."

24-hour format has no AM/PM to mix up, which is why aviation, medicine, and most transport timetables use it — the cost of guessing wrong on "8:00" is too high in those settings. Outside them, 12-hour format is still what most people read and speak day to day, so this calculator gives both. The two spots people actually get wrong: 12 AM is midnight, not noon, and 12 PM is noon, not midnight.

Handy for anything where the input field wants seconds or minutes instead of hours and minutes — cron schedules, video timestamps, session timeouts, that sort of thing.

Clock in at 09:15, clock out 3h 45m later at 13:00. Payroll software wants that as decimal hours, not hours-and-minutes.

1. Minutes as a fraction of an hour: 45 ÷ 60 = 0.75.
2. Add the whole hours: 3 + 0.75 = 3.75 decimal hours.
3. At, say, ₹200/hour: 3.75 × ₹200 = ₹750.00 for the shift.

The mistake worth guarding against is reading 45 minutes as a raw decimal instead of 0.75 — minutes aren't already a percentage of 100, they're a fraction of 60, and the two only happen to agree at :00. At :30 they're nowhere close (.30 read directly vs the correct .50). Over a few dozen shifts a year, that slip is real money in the wrong direction.

Employers rarely pay on the exact clock time, though — most round to a fixed increment first:

The gap between rounding rules is usually small for one shift and easy to shrug off — it adds up over a pay cycle with several shifts, which is exactly why it's worth knowing which rule your employer actually applies rather than assuming exact-minute pay.

Spreadsheets store a time of day as a fraction of 24 hours — 12:00 PM is stored internally as 0.5, 6:00 AM as 0.25 — which is exactly the base-24 wraparound this page keeps coming back to, just hidden behind a cell format. Two things trip people up:

• To get decimal hours out of a time-formatted cell, multiply by 24. A cell showing 3:45 as a duration, times 24, gives 3.75 — the same number this page calculated by hand above.
• The default time format wraps at 24 hours, so a duration over a full day quietly shows the wrong number (25 hours displays as "1:00"). Switch the cell format to [h]:mm — square brackets around the h — to make it display total elapsed hours instead of wrapping.

Subtracting an end time from a start time that crosses midnight has the same problem in reverse: a plain B2-A2 goes negative and shows an error unless you add 1 (one full day) to the formula when the end time is on the next day, mirroring the +1,440-minutes rule from the manual calculation above.

Converting across time zones just means adding or subtracting the offset difference. India Standard Time is UTC+5:30 year-round — no daylight saving to track on this side — so IST to UTC is "subtract 5 hours 30 minutes." A rough reference for common destinations from IST:

The "winter/summer" split exists because those cities observe daylight saving and India doesn't, so the gap between IST and local time actually moves twice a year even though IST itself never changes. Singapore and Tokyo don't observe daylight saving either, so their offset from IST stays fixed. If a recurring call keeps landing at an odd time, a daylight saving transition on the other end is almost always the reason — worth a re-check close to the date, not just when you first schedule it.

• Convert to minutes before doing any addition or subtraction — never add hour:minute pairs directly.
• Minutes ÷ 60 gives decimal hours; minutes read as a raw decimal (45 → .45) is the error to watch for, every time.
• When a result crosses midnight, note the day change explicitly rather than just the new clock time.
• Double-check AM/PM right around noon and midnight — that's where 12-hour format actually bites.
• For payroll or billing, confirm whether the employer rounds to the nearest 15 or 6 minutes before comparing your own math to a payslip.
• For anything with real consequences — a flight connection, a medication schedule — write the calculation out rather than doing it in your head.

Every time-arithmetic mistake traces back to the same shortcut: working directly with hour:minute pairs instead of converting to a single unit first. Convert to minutes, do the add or subtract, convert back — that one habit handles midnight wraparounds, 12-hour/24-hour conversions, and decimal-hour payroll figures without needing a different method for each case.

Figures are computed live from the start time and duration you entered (or the illustrative defaults shown) using standard 24-hour clock arithmetic. Time zone offsets are general reference points, not a substitute for checking current figures against an authoritative source before relying on them for time-critical scheduling or actual wage calculations.