The Time-to-Decimal Formula Explained

The formula

decimal_hours = h + (m / 60) + (s / 3600)

Plain-English version:

1. Take your hours count as-is. That part’s already in base 10.
2. Convert minutes to hours: divide by 60 (because there are 60 min in an hour).
3. Convert seconds to hours: divide by 3,600 (60 min × 60 sec).
4. Add the three.

You can verify the formula by substituting an obvious case: 1:30:00 should be 1.5 hours. Plug in: 1 + 30/60 + 0/3600 = 1 + 0.5 + 0 = 1.5. ✓

Why ÷ 60? A unit-conversion derivation

Think of minutes and hours as units, the way a scientist would. Each minute is a constant fraction of an hour:

1 min = (1 hr) / 60
      = 0.01666… hr

So if you have m minutes and want to express them in hours, you multiply by the unit-conversion factor:

m minutes × (1 hr / 60 min) = m/60 hours

Notice how the min units cancel, leaving hours. That’s exactly the same operation as converting kilometers to miles, just less famous. The reason it feels strange when you first do it on a timesheet is that we usually think in HH:MM rather than as a single quantity.

Why some conversions terminate and others don’t

Look at this list:

• 15 min  =  15/60  =  1/4  =  0.25 ✓ clean
• 30 min  =  30/60  =  1/2  =  0.50 ✓ clean
• 20 min  =  20/60  =  1/3  =  0.333… repeats forever
• 10 min  =  10/60  =  1/6  =  0.1666… repeats forever
• 05 min  =  5/60  =  1/12  =  0.08333… repeats forever

The math rule is simple: a fraction terminates in base 10 if and only if its denominator (in lowest terms) has no prime factors other than 2 and 5. Because 10 = 2 × 5, denominators built from these primes can be expressed as a finite power of 10 in the numerator, which gives a terminating decimal.

Apply that rule to our list:

• 1/4  →  denominator 4 = 2²  →  terminates: 0.25
• 1/2  →  denominator 2  →  terminates: 0.5
• 1/3  →  denominator 3  →  doesn’t terminate (3 is foreign to base 10)
• 1/6  →  6 = 2 × 3  →  the 3 ruins it: doesn’t terminate
• 1/12  →  12 = 2² × 3  →  the 3 ruins it

Since 60 = 2² × 3 × 5, any minute count whose simplified fraction still contains a 3 will repeat. The only minute counts that produce clean decimals are 0, 15, 30, 45 (which simplify to denominators of 1, 4, 2, 4 respectively).

So why does payroll round?

Two reasons:

1. Storage. Most payroll systems store hours as a fixed-decimal number with 2 or 4 digits of precision. They literally cannot store 0.0833… exactly. Picking a quarter-hour rounding scheme aligns every stored value with the four clean fractions: 0.00, 0.25, 0.50, 0.75.
2. History. Mechanical time clocks couldn’t record sub-minute precision, and the people computing payroll on paper or basic calculators couldn’t spend extra time on per-minute math. The DOL recognized this by allowing quarter-hour rounding under FLSA, provided it’s neutral over time.

Floating-point arithmetic and the “0.30000000000000004” problem

If you’ve ever seen a payroll export with values like 7.749999999 or 0.30000000000000004, that’s a side effect of how computers represent decimals. JavaScript, Python (without decimal module), Excel, and most other tools use IEEE 754 double-precision floating-point under the hood — which represents numbers in binary, not decimal.

0.1 cannot be represented exactly in binary (just as 1/3 can’t be represented exactly in decimal). Adding 0.1 + 0.2 in JavaScript gives 0.30000000000000004, not 0.3. Multiplying 7.5 by 1 sometimes gives 7.499999999 because of cumulative tiny errors.

The fix is rounding at display time. Our calculator uses Number.toFixed(4) internally and rounds further for display. Most production payroll software uses fixed-point or arbitrary-precision arithmetic for currency calculations specifically to avoid this trap.

Excel’s special trick: time as a fraction of a day

Excel doesn’t store 7:45 as 7.75 internally. It stores it as 7.75 / 24 = 0.322916…, the fraction of a 24-hour day. Format the cell as Number and you’ll see this raw value.

That’s why =A1*24 recovers decimal hours: you’re re-multiplying by the day length to get back to hours. The same trick works in reverse: =A1/24 formatted as [h]:mm turns 7.75 back into 7:45.

The [h] brackets are crucial. Without them, Excel modulo-24 the result, so 32 hours displays as 8:00 (which is technically correct as “time of day” but wrong for “duration”).

The reverse formula

Going from decimal back to HH:MM:

h = floor(decimal)
remainder = decimal - h
m = round(remainder × 60)

// edge case: if rounding pushed m to 60, carry the hour
if (m === 60) { h += 1; m = 0; }

The carry case is rare but real: 7.99999 rounds the minutes to 60, which should become 8:00 not 7:60. Always check.

A short proof: why DOL 7-min ≈ round-to-quarter

The DOL 7-minute rule is mathematically equivalent to "round half up" applied to minute boundaries at multiples of 15. To see why:

• The midpoint between 0 and 15 minutes is 7.5 min.
• Standard rounding sends < 7.5 down to 0, ≥ 7.5 up to 15.
• The DOL rule says ≤ 7 down, > 7 up. The boundary differs by exactly half a minute.
• That half-minute means a punch at exactly 7:30.0 rounds up to 15 under DOL (because it’s > 7), but down to 0 under naive round-half-up. Almost every other minute count agrees.

For quarter-hour totals applied to aggregated decimal hours rather than individual punches, the two methods produce identical results in practice. The 7-minute distinction matters most when rounding individual punches in/out.

Putting it together

You now know:

• Why ÷ 60 works (unit conversion)
• Why some conversions don’t terminate (base-10 / base-3 mismatch)
• Why payroll software rounds (storage, history)
• Why decimal totals sometimes look weird (floating-point)
• How Excel handles time internally (fraction of a day)
• How to reverse the formula (and avoid the 60-minute carry bug)

For the practical “just convert this number” flow, jump to the calculator. For payroll-specific rounding rules, see the 2026 reference.