Time Calculator (Add & Subtract Hours)

Time Calculation Guide

What do I need to know about Adding and Subtracting Time?

Time arithmetic works in base 60 (minutes and seconds), unlike everyday arithmetic in base 10. When adding minutes, if the result exceeds 59, carry 1 to hours. Example: 3 hours 45 minutes + 2 hours 35 minutes = 5 hours 80 minutes = 6 hours 20 minutes. When subtracting, borrow 60 from the hours if needed: 5 hours 10 minutes − 2 hours 45 minutes → borrow 1 hour: 4 hours 70 minutes − 2 hours 45 minutes = 2 hours 25 minutes.

What should I know about Decimal Hours?

Decimal hours (used in timesheets and invoicing) express time as a decimal fraction of an hour. 0.25 hours = 15 minutes, 0.5 hours = 30 minutes, 0.75 hours = 45 minutes. To convert h:mm to decimal: decimal = hours + minutes/60. To convert decimal to h:mm: hours = integer part, minutes = decimal part × 60. Example: 8.75 hours = 8 hours and 0.75 × 60 = 45 minutes = 8:45.

What should I know about Timesheet Calculations?

For weekly timesheet calculations: add up all daily hours then convert to decimal for invoicing. If your rate is £35/hour and you work 8 hours 45 minutes: convert to decimal (8.75 hours), multiply by rate = £306.25. If calculating overtime (time and a half after 37.5 hours): total hours in decimal, subtract 37.5 for regular hours, multiply remainder by 1.5, sum regular and overtime pay. Always confirm overtime threshold with your employment contract.

What do I need to know about Time Zones and Date Arithmetic?

Adding time across midnight rolls the day forward. Adding 6 hours to 22:00 gives 04:00 the next day. For scheduling across time zones, always work in UTC first, then convert to local time — this avoids daylight saving time ambiguities. Duration and elapsed time calculations can use simple subtraction when the times are the same day; overnight calculations require adding 24 hours if the end time is earlier than the start time.

What do I need to know about Converting Between 12-Hour and 24-Hour Time?

The 24-hour clock (also called military time) numbers hours from 00 to 23 with no AM/PM label, while the 12-hour clock repeats 1 through 12 twice daily with an AM or PM suffix. Converting from 24-hour to 12-hour: for hours 00–11, it's AM (00:00 becomes 12:00 AM, and 00:01–11:59 keep the same number with AM, except hour 0 which displays as 12); for hours 13–23, subtract 12 and label PM (14:30 becomes 2:30 PM); hour 12 stays as 12:00 PM (noon). Converting the other way, from 12-hour to 24-hour: AM hours keep their number except 12 AM, which becomes 00; PM hours add 12 except 12 PM, which stays as 12. The trickiest points for most people are midnight (12:00 AM = 00:00) and noon (12:00 PM = 12:00) — both display '12' on a 12-hour clock despite being exactly 12 hours apart, which is a frequent source of scheduling errors for flights, medical dosing, and international meetings.

What's the key thing to understand about Why Time Uses Base 60?

Unlike most modern measurement, time doesn't divide into tens — there are 60 seconds in a minute and 60 minutes in an hour — because this system dates back roughly 4,000 years to ancient Babylon, which used a base-60 (sexagesimal) number system rather than our modern base-10. Sixty was a practical choice for ancient mathematicians because it divides evenly by many small numbers (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, and 30), making fractions and divisions far easier to compute by hand than a base-10 system would allow for the same purpose. This is also why a circle has 360 degrees (60 × 6) and why some older measurement and navigation systems used minutes and seconds of arc. Because clock arithmetic uses base 60 rather than base 10, adding or subtracting times requires 'carrying' at 60 rather than at 10 — 45 minutes plus 30 minutes isn't 75 minutes displayed as-is, it's 1 hour and 15 minutes, which is precisely the conversion this calculator automates.

What do I need to know about UTC, Time Zones, and Daylight Saving Adjustments?

UTC (Coordinated Universal Time) is the reference time standard that every time zone is defined relative to, expressed as an offset like UTC+1 or UTC-5. Converting a time between zones means adding or subtracting the difference in offsets — a meeting at 3:00 PM UTC+1 (London, winter) is 10:00 AM UTC-4 (New York, winter) because the offset difference is 5 hours. Daylight saving time complicates this further, since clocks shift forward or back by an hour on dates that differ by country, and some regions (much of the tropics, and places like most of Arizona in the US) don't observe it at all — so the offset between two cities can change twice a year even though neither city's own local rules changed. For this reason, software that schedules events across time zones is generally built to store times in UTC internally and only convert to local time for display.

Worked Payroll Example: A Full Weekly Timesheet

Converting a full week of clock-in and clock-out times into a single decimal-hours total for payroll is the most common real-world use of time arithmetic. The table below works through a typical five-day week.

Each day converts the same way: minutes ÷ 60 gives the decimal fraction, so 30 minutes = 0.50, 15 minutes = 0.25, and 45 minutes = 0.75. Once every day is in decimal form, the days simply add normally (7.50 + 8.25 + 8.00 + 7.75 + 5.50 = 37.00) — this is exactly why payroll systems convert to decimal hours before summing, rather than trying to add h:mm values directly across a whole week. At a pay rate of £14.50 per hour, this week's gross pay is 37.00 × £14.50 = £536.50. If any day crosses into overtime (commonly defined as hours beyond 37.5 or 40 per week, depending on contract), the regular and overtime portions are split and the overtime hours multiplied by the appropriate premium rate — typically 1.5× — before being added back to the regular total.

Why Simple Duration Calculators Don't Handle Daylight Saving Time

Most duration calculators, including straightforward start-time/end-time tools, work purely from the clock numbers typed in — they subtract one time from another and roll over at midnight, with no awareness of whether a Daylight Saving Time (DST) transition happened in between. This matters because DST transitions change the actual elapsed real-world time without changing what the clock reads in the normal way. In spring, clocks move forward by one hour ('spring forward'), which means a duration that looks like, say, 8 hours by the clock actually represents only 7 hours of real elapsed time, because one of those clock-hours never happened. In autumn, clocks move back by one hour ('fall back'), so a duration that looks like 8 hours by the clock actually represents 9 hours of real elapsed time, because that hour occurred twice. A naive calculation spanning a DST changeover night will therefore be off by exactly one hour in one direction or the other — a genuine, well-documented pitfall for payroll systems, flight-duration calculators, and any script that treats local wall-clock time as if it always advances at a constant rate. The safe way around it: convert to UTC (which never has DST transitions) before computing the duration, then only convert back to local time for display, which is exactly the approach described in the UTC section above and the standard practice in software that must get this right.

Worked Example: Calculating a Duration in Years, Months, and Days

Converting a long date range into years, months, and days is trickier than it first looks, because calendar months are not all the same length, so you can't just divide the total number of days by 30. Worked example: how long is the period from 10 June 2024 to 27 October 2026? Step 1 — count whole years first: from 10 June 2024, adding 2 full years lands on 10 June 2026, which is still before the end date, so the result includes at least 2 years. Step 2 — from 10 June 2026, count whole months: adding 4 months lands on 10 October 2026, still before the end date, so that's 4 more months. Step 3 — from 10 October 2026, count the remaining days to 27 October 2026: that's 17 days. Putting it together: the period from 10 June 2024 to 27 October 2026 is exactly 2 years, 4 months, and 17 days. Checking the logic in reverse confirms it: 10 June 2024 + 2 years = 10 June 2026; + 4 months = 10 October 2026; + 17 days = 27 October 2026 ✓. This calendar-aware, step-down method (years, then months, then days) is what correctly handles the real-world irregularity of month lengths, unlike a naive 'total days ÷ 365.25' estimate, which gives only an approximate answer and can be off by several days depending on which months and leap years fall inside the range.