Time between two clock times
Convert both to minutes since midnight, subtract, and read back:
duration (min) = (h2×60 + m2) − (h1×60 + m1)
Worked example, 09:30 to 17:15:
- Start = 9×60 + 30 = 570 minutes
- End = 17×60 + 15 = 1,035 minutes
- Duration = 1,035 − 570 = 465 minutes = 7 h 45 m
The step that catches people out is crossing midnight. From 22:00 to 06:00 the raw subtraction gives −960, which is meaningless. Adding 1,440 (minutes in a day) gives 480 minutes = 8 hours. The result is only ambiguous if the interval could be longer than 24 hours, and for a same-or-next-day question the convention is always the short way round.
Days between two dates
Convert both dates to a day count and subtract. The subtle part is not the subtraction — it is what a "day" means and where leap years enter.
The Gregorian rule: a year is a leap year if it is divisible by 4, except if divisible by 100, except again if divisible by 400. So 2024 is a leap year (÷4), 1900 is not (÷100 but not ÷400), and 2000 is (÷400).
Worked example, 2026-10-04 to 2026-10-18:
- October has 31 days, so from the 4th to the 18th is 18 − 4 = 14 days = 2 weeks exactly
- Neither 2024 nor a leap February is in range, so no adjustment
Two questions the raw number does not answer: are both endpoints included? (a 14-day span can be 14 nights or 15 calendar dates) and do weekends count? — for project planning they usually should not, which is why the working-day count differs from the calendar count.
Adding and subtracting a duration
Adding minutes to a time is modular arithmetic on a 24-hour clock. A common practical case is a countdown: 23:50 plus 20 minutes is 00:10 the next day, not 24:10.
result = (start_min + delta) mod 1440
Subtracting uses the same formula with a negative delta, and then take the result back into 0-1439. The worked example in the calculator shows the backward case explicitly, because the modulo of a negative number is negative in most languages and needs correcting — a small thing that reliably produces off-by-one-day errors in scheduling code.
Why time zones make this harder than it looks
All of the above assumes both times are in the same zone, which is rarely true across a flight or a remote meeting. Working in UTC removes the ambiguity:
- Convert the local time to UTC by subtracting its offset, then convert UTC to the target zone by adding the target's offset.
- The offset is not fixed. Most of the world shifts by an hour twice a year, and the shift dates differ between the US (second Sunday in March, first in November) and the EU (last Sunday in March and October), so for three weeks each year the two disagree.
- On the spring transition, local times from 01:30 to 02:59 do not exist. On the autumn one, they happen twice.
- Some offsets are not whole hours — India is +5:30, Nepal +5:45, parts of Australia +9:30 — so any conversion that assumes integers is wrong for a large part of the world.
The time zone converter handles the offsets, and the time zone guide covers the daylight saving traps in detail.
Frequently asked questions
How do I calculate the time between two times?
Convert each to minutes since midnight, subtract, and convert back. If the result is negative the interval crosses midnight, so add 1,440 minutes. From 09:30 to 17:15 that is 1,035 - 570 = 465 minutes, or 7 hours 45 minutes.
How do I find the number of days between two dates?
Convert both dates to a day count and subtract, adjusting for leap years. A year is a leap year if divisible by 4, except if divisible by 100, except if divisible by 400. From 2026-10-04 to 2026-10-18 is exactly 14 days.
How do I know if a year is a leap year?
Divide by 4, except if divisible by 100, except again if divisible by 400. So 2024 is a leap year, 1900 is not, and 2000 is. February then has 29 days instead of 28, which shifts every subsequent date in the count by one.