The formula: why you divide by 3600
One hour contains 60 minutes, and each of those minutes contains 60 seconds — so one hour holds exactly 3,600 seconds. That single fact is the entire conversion formula: take your seconds, divide by 3,600, and you have decimal hours. Ninety seconds becomes 90 ÷ 3600 = 0.025 decimal hours. Eighteen hundred seconds becomes 1800 ÷ 3600 = 0.5 decimal hours, which is the same as 30 minutes. The arithmetic never changes; only the number on top of the division changes.
The hundredths version of decimal hours is what most payroll and billing systems store. Two decimal places means the smallest representable unit is 0.01 hours, which equals 36 seconds (0.01 × 3600). So any chunk of time shorter than 36 seconds rounds to zero in a two-decimal system, and a 37-second task rounds to 0.01 hours. Four-decimal precision brings the smallest unit down to 0.0001 hours, or 0.36 seconds — fine enough for laboratory or athletic timing, though payroll rarely needs anything beyond four places.
A useful shortcut for mental math: 10 seconds is 0.002778 decimal hours, 60 seconds is 0.016667, and 360 seconds is exactly 0.1. Because 360 divides evenly into 3600, every 360-second block adds a clean 0.1 to your decimal. Six minutes is 360 seconds is 0.1 hours — the same anchor that makes minute-to-decimal conversion manageable, now traceable all the way back to raw seconds.
Worked examples table: seconds to decimal hours
The table below covers the most common second counts encountered in payroll adjustments, video production, athletic timing, and billing rounding. The "decimal hours (4 dp)" column is the full-precision value; the "rounded to hundredths" column is what a standard two-decimal payroll field would store. The "clock equivalent" column is the HH:MM:SS form of the same interval for cross-reference.
<table style="width:100%;border-collapse:collapse;font-size:0.92em"><thead><tr style="background:#f3f4f6"><th style="text-align:left;padding:6px 10px;border:1px solid #d1d5db">Seconds</th><th style="text-align:right;padding:6px 10px;border:1px solid #d1d5db">Decimal hours (4 dp)</th><th style="text-align:right;padding:6px 10px;border:1px solid #d1d5db">Rounded to 0.01</th><th style="text-align:right;padding:6px 10px;border:1px solid #d1d5db">Clock equivalent</th></tr></thead><tbody><tr><td style="padding:5px 10px;border:1px solid #d1d5db">30</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0083</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.01</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:00:30</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">60</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0167</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.02</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:01:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">90</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0250</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.03</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:01:30</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">120</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0333</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.03</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:02:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">180</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0500</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.05</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:03:00</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">300</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.0833</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.08</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:05:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">360</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.1000</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.10</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:06:00</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">600</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.1667</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.17</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:10:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">900</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.2500</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.25</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:15:00</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">1200</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.3333</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.33</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:20:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">1800</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.5000</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.50</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:30:00</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">2700</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.7500</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0.75</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">0:45:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">3600</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1.0000</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1.00</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1:00:00</td></tr><tr style="background:#f9fafb"><td style="padding:5px 10px;border:1px solid #d1d5db">5400</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1.5000</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1.50</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">1:30:00</td></tr><tr><td style="padding:5px 10px;border:1px solid #d1d5db">7200</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">2.0000</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">2.00</td><td style="text-align:right;padding:5px 10px;border:1px solid #d1d5db">2:00:00</td></tr></tbody></table>
A few rows deserve comment. The 120-second row rounds to 0.03, not 0.04, because 0.0333 is closer to 0.03 than to 0.04. The 300-second row rounds to 0.08 for the same reason — 0.0833 is closer to 0.08. Whenever precision matters — an athlete shaving tenths off a personal record, or a video editor billing for render time — use the four-decimal column and carry more places than the table shows. For payroll where quarter-hour rounding applies anyway, the two-decimal column is the right one because further precision only creates false accuracy against a rounded output.
Converting hours, minutes, and seconds together
Timestamps from video tools, GPS loggers, and scientific instruments often arrive in H:MM:SS format. Converting 2:14:37 — two hours, fourteen minutes, thirty-seven seconds — into decimal hours is a three-piece calculation: the hours stay as 2, the minutes become 14 ÷ 60 = 0.2333, and the seconds become 37 ÷ 3600 = 0.010278. Add all three: 2 + 0.2333 + 0.010278 = 2.2436 decimal hours (rounded to four places). The shortcut formula is H + (M / 60) + (S / 3600) — one expression that handles all three units at once.
A spreadsheet column of HH:MM:SS timestamps needs exactly this formula. If cell A2 holds a duration entered as text — say, the string "2:14:37" — the cleanest approach is to parse it with TIMEVALUE(A2) × 24, which returns the decimal hours directly in most spreadsheet applications. If the cell is formatted as a time (not text), the × 24 alone is sufficient because the spreadsheet already stores the value as a fraction of a day. Either route lands at the same number; the trap is mixing the two without noticing, which produces values that look right at small counts and are wrong by a factor of 24 for any entry over an hour.
A real example from video production: a rough-cut timeline runs 1:47:22. The producer needs to bill 1.79 hours (rounded to 0.01). Working it: 1 + (47/60) + (22/3600) = 1 + 0.7833 + 0.00611 = 1.7894 decimal hours, rounds to 1.79. If the next session is 0:58:44, the conversion is 0 + (58/60) + (44/3600) = 0 + 0.9667 + 0.01222 = 0.9789, which rounds to 0.98 hours. Total billed for both sessions: 1.79 + 0.98 = 2.77 hours. No minutes-and-seconds arithmetic, no carries, just two plain addition steps after the initial divide.
Where second-level precision actually matters
Payroll rarely cares about individual seconds — shifts are logged in minutes, and the rounding increments used by federal regulations (29 CFR § 785.48) are at least 5 minutes. But several other domains track time at the second level and need a clean path to decimal hours. Video and audio production is the most common: non-linear editing timelines count frames at 23.976, 25, or 29.97 frames per second, and render logs report processing time in HH:MM:SS. When a post-production house bills by the hour, each session's render time must become a decimal for the invoice. The formula is the same; only the source format differs.
Athletic coaching and sports science measure performance to the tenth or hundredth of a second. A 400-meter split of 52.34 seconds is 52.34 ÷ 3600 = 0.014539 decimal hours — not a number anyone would present to an athlete, but a useful one inside a spreadsheet that compares effort across weeks. GPS running watches export pace in minutes-and-seconds per kilometer; backing that into decimal hours per workout lets a coach sum effort across sessions in one column. The arithmetic is always ÷ 3600.
Manufacturing and process engineering track machine uptime in seconds from SCADA logs. A conveyor that ran 23,400 seconds in a shift converts to 23400 ÷ 3600 = 6.5 hours — straightforward, but the intermediate step matters when the log is raw seconds and the OEE formula expects decimal hours. Industrial IoT platforms often output seconds since epoch, and the conversion to decimal shift hours requires exactly this divide. Quality engineers who know it can verify uptime calculations without waiting for the plant's reporting system to process the data.
Scientific experiments log elapsed time at sub-second granularity. A chemistry reaction log showing 8,647 seconds converts to 8647 ÷ 3600 = 2.4019 hours. Telescope observation logs, particle detector runs, and clinical trial protocol durations all land on the same division. In these contexts, carrying four or six decimal places is appropriate — the difference between 2.4019 and 2.40 can represent nearly seven seconds of observation time, which may be the margin between a published result and a retracted one.
Rounding seconds in payroll: the 36-second unit
When a payroll system stores decimal hours to two places, it is implicitly rounding to the nearest 0.01 hours, which is 36 seconds. Every punch or duration that falls between round multiples of 36 seconds gets mapped to the nearest 0.01. The direction of that rounding — up or down — determines whether the employee gains or loses fractions of a cent per occurrence. For individual rows it is invisible; for a workforce of 500 over a year it can be thousands of dollars.
The Department of Labor's rounding guidance under 29 CFR § 785.48 says that rounding is permissible as long as it averages out over time and does not systematically undercompensate employees. That standard was written with minute-level rounding in mind, but courts have extended its logic to any rounding increment. A company that always rounds a 37-second residual down to 0.01 hours rather than up to 0.02 is doing exactly the kind of consistent tilt the regulation disallows. The practical check is to convert a sample of raw second-level punches here, apply the stated policy, and see whether the rounded totals are consistently above or below the exact decimal — if they're always below, the rounding is not neutral.
Most businesses never encounter second-level punch data directly because biometric clocks and most time-and-attendance terminals record to the minute. But exceptions exist: automated badge readers, API-integrated access-control systems, and mobile clock-in apps all log the exact clock time including seconds, which means the raw data holds sub-minute precision even when the display does not. Knowing how your system handles those trailing seconds — truncates, rounds to nearest, or ignores — is the step most payroll audits skip. Running a spot check of exact versus rounded totals for a sample week takes minutes and surfaces systematic patterns that a quarterly audit would miss entirely.
Seconds in Excel and Google Sheets: three traps to avoid
The first trap is format confusion. Excel stores a time like 0:02:30 as a fraction of a day — 0.001736. Multiply by 24 and you get 0.041667 hours, which is 150 seconds ÷ 3600 = 0.041667. That math is correct. But if you multiply by 60 instead of 24, you get 0.104167, which looks like minutes-as-decimal and is meaningless. The rule: multiply any Excel time value by 24 to get decimal hours, full stop. If your column holds pure seconds as plain numbers, divide by 3600 instead.
The second trap is the [h]:mm:ss display format and what happens to it in arithmetic. A cell formatted as [h]:mm:ss can display durations longer than 24 hours correctly, like 26:15:44, but as soon as you add or subtract two such cells, the result can silently shift to a fraction-of-day representation again. The safe practice is to convert to decimal hours once — =A2*24 for time-formatted cells, =A2/3600 for plain-number seconds — and do all arithmetic on the decimal column. Convert back to display format only for the final output row, and never mix the two representations in intermediate calculations.
The third trap is the TIMEVALUE function's behavior on durations over 24 hours. TIMEVALUE("25:00:00") returns an error, because the function was designed for time-of-day values, not durations. For durations reported as text strings, split the string with FIND or LEFT/MID/RIGHT, parse the hours, minutes, and seconds separately as numbers, and apply the H + M/60 + S/3600 formula manually. A helper column that does this parsing is two to four cells of formula; done once, it handles any duration the log can produce. Paste the column into any project and it works without modification, because the arithmetic is just division — no locale dependency, no date system dependency, no format dependency.
A worked spreadsheet example: column A holds raw seconds from a server log (plain numbers like 8647, 302, 15033). Column B holds the formula =A2/3600, formatted as a plain number with four decimal places. Column C holds =ROUND(B2,2) for the two-decimal payroll version. Cell B1 shows 2.4019 for 8647, 0.0839 for 302, and 4.1758 for 15033. The SUM of column B is the total decimal hours for the log period. No manual conversion, no Excel time-format ambiguity, no cross-locale rounding surprises. The divide-by-3600 in column B is the only operation that matters.
How do seconds map to decimal hours in payroll and billing systems?
Most timekeeping and billing platforms store work durations as decimal hours rounded to two or four places. When your time-tracking software exports raw seconds — from a stopwatch, a server-side timestamp, or an API that counts elapsed milliseconds — you need to convert those seconds to the decimal format the payroll engine expects before importing. The table below shows the most common reference values, from a single second up to a full eight-hour shift, so you can verify your conversion at a glance before submitting hours for approval.
Reference conversion table — seconds to decimal hours and minutes:seconds display: Seconds | Decimal Hours | MM:SS ---------|---------------|------ 60 | 0.0167 | 01:00 120 | 0.0333 | 02:00 360 | 0.1000 | 06:00 600 | 0.1667 | 10:00 900 | 0.2500 | 15:00 1 800 | 0.5000 | 30:00 2 700 | 0.7500 | 45:00 3 600 | 1.0000 | 60:00 5 400 | 1.5000 | 90:00 7 200 | 2.0000 | 120:00 18 000 | 5.0000 | 300:00 28 800 | 8.0000 | 480:00 Every 360-second increment adds exactly 0.1 to the decimal, making the table predictable: 720 seconds is 0.2, 1080 is 0.3, and so on.
In billing systems for legal, consulting, or creative work, the smallest billable unit is usually 0.1 hour (360 seconds) or 0.25 hour (900 seconds). A task that took 412 seconds is 0.1144 decimal hours — it rounds to 0.1 on a tenth-of-an-hour grid or to 0.25 on a quarter-hour grid. Under-rounding bills the client for less time than was spent; over-rounding adds time that was not spent. The choice of rounding increment is usually set in the engagement letter or billing policy, not in the conversion tool, but the converter must output the unrounded decimal so the billing system can apply its own rounding rule consistently.
For payroll specifically, the Fair Labor Standards Act requires that any rounding method average out across punches rather than systematically shaving employee hours. If your timekeeping system captures durations in seconds and then rounds to the nearest 0.25 hour before importing to payroll, a 899-second task (0.2497 hours) rounds down to 0.25 while a 901-second task (0.2503 hours) rounds up to 0.25 — a near-symmetric result. But if the threshold is biased — always rounding down at exactly 0.25, for instance — the systematic loss accumulates. Reviewing raw-second totals against paid decimal totals quarterly is the fastest way to detect drift before it becomes a wage claim.
Mobile apps and browser-based timers increasingly export seconds as integers in their CSV or JSON output — a column labeled 'duration_seconds' or 'elapsed_sec'. Importing that column directly into a payroll field labeled 'hours' without dividing by 3600 is a silent data-type error: a 3600-second task would appear as 3600 hours, which payroll validation software may cap or flag, but smaller values like 28 seconds imported as 28 hours will pass validation silently if the field accepts three-digit values. The safe habit is to add a dedicated conversion column — divide by 3600 — and import only that derived column into the hours field.
What mistakes do people make converting seconds to decimal hours?
The single most common error is treating seconds as if they were fractions of a minute rather than fractions of an hour. Someone who records 30 seconds of a task may write '0.30 hours' in their timesheet, reasoning that 30 is half of 60. But 0.30 hours is 18 minutes, not 30 seconds. Thirty seconds is 30 ÷ 3600 = 0.0083 decimal hours — more than 200 times smaller than 0.30. On an hourly rate of $50, that single digit-placement error inflates one entry by $14.58. Multiplied across dozens of daily entries, the overcharge becomes material within a week.
A related trap is confusing the HH:MM:SS notation 1:30:00 with the decimal value 1.5. Both represent one hour and thirty minutes, but a programmer or analyst who sees '1:30:00' in a data export and stores it as the float 1.3 (stripping the colons) has introduced a 12-minute error per entry. The correct conversion for 1:30:00 is 1 + 30/60 + 0/3600 = 1.5000. If you see a column of values like 1.3, 2.15, or 0.45 that came from HH:MM:SS strings, those are almost certainly corrupted by colon-stripping rather than proper arithmetic conversion.
Another frequent mistake is applying the divide-by-60 rule (minute-to-decimal conversion) to seconds instead of the divide-by-3600 rule. Minutes and seconds share the same sexagesimal base, but the divisors differ by a factor of 60. If you paste a seconds column into a minutes-to-decimal converter by mistake, every value will be 60 times too large. A server log recording a 7,200-second job run would return 120.0 ‘decimal hours’ instead of the correct 2.0 decimal hours. The clue is proportion: no single job should exceed the total hours in a workday (8.0 to 10.0 for most roles), so any decimal output greater than 24 from a single entry signals a wrong-unit conversion.
Precision loss from premature rounding is subtler but equally costly at scale. If you round 6,500 seconds to 1.81 hours (two decimals) before summing ten such entries, your total is 18.10. If instead you sum the raw decimals first (6500 ÷ 3600 = 1.80556 each, ten of them = 18.0556) and round at the end, you get 18.06. The difference of 0.04 hours is 2.4 minutes — small per entry, but over a 1,000-row export the accumulated rounding drift can reach 20+ minutes. The rule is: divide by 3600 at full precision, sum all rows, then round the final total once to the desired number of decimal places.
A self-check checklist for seconds-to-decimal conversions: (1) Confirm the source column is genuinely in seconds, not milliseconds or minutes — divide one known value by hand and verify it matches the context. (2) Divide by 3600, not 60. (3) Check that no single result exceeds 24.0, since no single-day entry should. (4) Avoid entering a time like ‘0:00:30’ into a calculator as the number 0.003 — parse the H, M, S components explicitly. (5) If importing to payroll software, check the target field’s unit label: a field expecting decimal hours should not receive raw seconds. (6) Cross-reference with this page’s worked-examples table for common reference values like 900 = 0.25 and 1800 = 0.50. Catching any one of these errors before submission is worth more than all the mental-math shortcuts combined.
Seconds in attendance systems and piece-rate payroll
Most badge readers and biometric terminals export punch data as HH:MM:SS — or, more often, as an integer count of seconds since midnight. A worker who badges in at 07:43:20 has been on-site for 7 hours, 43 minutes, and 20 seconds since midnight, which the terminal stores as 27,800 seconds (7 × 3600 + 43 × 60 + 20). To convert that punch to the decimal the payroll system wants: 27,800 ÷ 3600 = 7.7222 hours. If the shift ended at 17:28:45 (62,925 seconds since midnight), the duration is 62,925 − 27,800 = 35,125 seconds, and 35,125 ÷ 3600 = 9.7569 decimal hours. At a straight-time rate of $16.50, the gross for that shift is 9.7569 × $16.50 = $161.09.
Overtime enters as soon as the weekly total exceeds 40.00 decimal hours under the FLSA. Suppose the same worker clocked 38.25 regular hours Monday through Thursday, and Friday’s shift came to 2.3194 decimal hours (8,350 seconds). The running total becomes 40.5694 hours. The first 1.75 hours on Friday (40.00 − 38.25) pay at the straight rate; the remaining 0.5694 hours pay at 1.5× the regular rate. Working from seconds all the way through means the boundary splits cleanly on the decimal — no need to think in minutes-and-seconds at the overtime threshold.
Piece-rate operations add a second complication. A garment worker or agricultural employee who earns per unit rather than per hour still has a minimum-wage floor for every hour worked. To verify compliance, the employer divides total piece-rate earnings by total hours worked — and total hours worked must be computed from the raw seconds on the time clock, not rounded to the nearest quarter hour in the workers’ favor. A 10-hour shift that rounds to 10.00 decimal hours looks fine; the same shift measured at 36,540 seconds is actually 10.15 hours, giving a lower implied hourly rate. The difference can push a borderline piece-rate situation out of compliance with state minimum-wage law.
The 60-base trap: why 0.50 hours is not 50 minutes
The single most persistent misconception in decimal-time arithmetic is reading the decimal portion as if it were minutes. A pay stub showing 8.50 hours is not 8 hours and 50 minutes; it is 8 hours and 30 minutes. 0.50 × 60 = 30. Similarly, 0.10 hours is 6 minutes, 0.25 hours is 15 minutes, and 0.75 hours is 45 minutes. None of those match their digit-face values in minutes. The confusion is natural — we write time in base 60 all day — but decimal hours are base 10, and mixing the two systems produces errors that always point in a consistent direction: the decimal-as-minutes reading overstates durations below the half-hour mark and understates those above it.
Common misread zones and their financial weight: reading 0.50 hours as 50 minutes overstates by 20 minutes, which at $18.00/hr is $6.00 per occurrence. Reading 8.25 as 8 hours 25 minutes instead of 8 hours 15 minutes inflates one shift by 10 minutes, or $3.00. Reading 0.1 as 10 minutes instead of 6 minutes adds 4 minutes per entry; across a 50-entry monthly invoice that is 200 phantom minutes, about $60 at $18.00/hr. The errors accumulate silently because no single one is large enough to trigger an audit. The <a href="/timesheet-decimal-converter">timesheet decimal converter</a> shows the clock-time equivalent next to every decimal total precisely to surface these misreadings before they reach payroll.
The same trap appears at the seconds level. An entry of 3,600 seconds converts to 1.0000 decimal hours, easy enough. But 3,780 seconds is 1.0500 hours, not 1 hour and 5 minutes — it is 1 hour and 3 minutes (180 seconds = 3 minutes). If you see a decimal like 1.05 and want the clock-time equivalent, the correct move is 0.05 × 60 = 3 minutes, not 5 minutes. Carrying that through: 1.05 hours = 1:03:00, and 1.25 hours = 1:15:00. The anchor to hold is that each 0.01 decimal hour equals 36 seconds, so every two-decimal step from 1.00 to 1.01 covers 36 seconds of real time, never a full minute.
Centihours, tenth-hours, and why medical billing picks different scales
Decimal hours come in several granularities, and different industries settled on different ones for reasons that have little to do with precision and a lot to do with the legal environment they operate in. The two most common are tenth-hour billing (0.1-hour increments, 6-minute resolution) and quarter-hour payroll (0.25-hour increments, 15-minute resolution). A less common but real unit is the centihour — 0.01 hours, 36 seconds — which shows up in specialized billing software for telecommunications and some engineering firms that need finer resolution than 6 minutes without tracking raw seconds.
Medical and legal billing typically uses tenth-hour increments and, critically, rounds up rather than to-nearest. A 7-minute phone call bills as 0.2 hours, not 0.1, because the engagement letter specifies billing in tenths and any work begun in a new tenth counts as the whole tenth. At $350/hr, that 7-minute call costs the client $70 rather than $35. Workers covered by the Fair Labor Standards Act (FLSA) get the opposite treatment: 29 CFR § 785.48 permits rounding only when it averages out over time, and rounds to-nearest at the 7.5-minute midpoint of a 15-minute increment. An employee who punches in at 7:53 gets credited for 7:45 under a quarter-hour system — that 8-minute rounding loss costs them $2.47 at $18.50/hr on a single punch. See the <a href="/hours-to-decimal">hours to decimal converter</a> for the same rounding logic applied to whole-hour inputs.
The centihour occupies a middle ground that explains its niche. Telecom billing in the 1980s and 1990s used it because 36-second increments matched the switching hardware’s measurement resolution and were small enough that no single rounded entry would exceed 18 seconds of error. Scientific instruments and athletic timing sometimes use it for the same reason: meaningful precision without the complexity of tracking seconds separately. For most payroll work, centihour precision is overkill — the <a href="/minutes-to-decimal-hours">minutes to decimal hours</a> path handles everything most timesheets need, and rounding to two decimal places there already gives 36-second resolution. Where centihours matter is in any system that must export seconds and must guarantee that the two-decimal display is always the correctly-rounded version of the underlying seconds value, not a truncation.
Batch conversion discipline: rounding one row at a time loses minutes by Friday
A common spreadsheet habit is to format each time-duration cell to two decimal places as soon as it is entered. The display looks clean, but the underlying value has been rounded before any addition happens — and those small rounding differences compound across the week. Consider a worker with five shifts: 28,450 s, 31,770 s, 29,940 s, 30,600 s, and 27,900 s. Rounded individually: 7.90 + 8.83 + 8.32 + 8.50 + 7.75 = 41.30 hours. Summed at full precision first: (28,450 + 31,770 + 29,940 + 30,600 + 27,900) = 148,660 s ÷ 3600 = 41.2944 hours, rounds to 41.29. The row-by-row method overstates the week by 0.01 hours — 36 seconds — which at $18.50/hr is $0.19. Across 40 employees for 52 weeks, that rounds-up habit costs roughly $390 per year in wages that were never actually earned.
The fix requires only a layout change in the spreadsheet. Keep a raw-seconds column that sums with no formatting applied. One formula at the bottom divides the total seconds by 3600 and rounds once. The formatted display columns can show two decimal places all they want; the payroll number must come from that single bottom-of-column formula, not from adding the already-rounded row cells. Many payroll integrations reinforce this: QuickBooks Time stores all entries in seconds internally and converts to decimal hours only on the report layer, which is exactly the sum-first-round-last discipline in system form.
Overnight shifts and missing punches need special handling in a batch run. A shift that starts at 23:14:30 and ends at 07:02:15 the next day spans two calendar dates. In seconds: the first segment runs from 83,670 s (23:14:30 since midnight) to 86,400 s (midnight) = 2,730 s; the second segment runs 0 to 25,335 s (07:02:15) = 25,335 s; total = 28,065 s = 7.7958 decimal hours. Spreadsheets that use DATE + TIME values handle this automatically if the timestamps carry date information; systems that store only HH:MM:SS without a date will wrap to negative durations and require the manual add-86400 correction before dividing by 3600. Identifying which entries hit midnight before running the batch is the five-second pre-check that prevents an entire column of corrupt decimal values.