Convert time to decimal without the mental math
Anyone who has ever closed a timesheet on a Friday knows the routine: the system wants 8.5, but you wrote 8:30. This time to decimal calculator converts clock time into decimal hours the moment you type, with no buttons to press and no formulas to remember. It handles any value from a few minutes to hundreds of hours, and it also works in reverse when you need to read a decimal paycheck figure back as real time.
The conversion divides minutes by 60, because one minute is one sixtieth of an hour. That is why the decimal equivalents of quarter hours are so tidy — .25, .50 and .75 — and why everything else, like 7 minutes (0.1167) or 22 minutes (0.3667), is awkward enough that a calculator earns its keep.
The idea is older than the spreadsheet. In October 1793, Revolutionary France decreed a decimal day: ten hours of one hundred minutes, each minute of one hundred seconds. Clocks were built for it, offices tried it, and by 1795 the country had quietly gone back to twenty-four — but the instinct survived. What payroll actually uses today is a smaller compromise: keep the 24-hour day, decimalize only the minutes. That leaves a handful of anchor values worth memorizing — 15 minutes is 0.25, 30 is 0.5, 45 is 0.75, and any 6-minute chunk is exactly 0.1. One minute always contributes 0.0167, so 8:40 works out to 8.67 without a tool. If you can carry those six numbers you can eyeball most of a timesheet; the calculator is for the other values and for proving you right.
Built for timesheet day and invoicing day
Time tracking software such as TSheets, When I Work and Homebase all report in decimal hours, and most accounting tools that import that data expect the same format. If you keep your own hours in a notebook or spreadsheet using clock notation, this page is the fastest bridge between your records and theirs: convert, copy, paste, done.
Freelancers and consultants use it the same way when an invoice line item needs to say 6.25 hours rather than 6:15. Clients rarely dispute a decimal they can multiply by the rate in one step, and the number in the converter matches what every major payroll platform would compute for the same input.
Other trades decimalize for their own reasons. Pilots log flight time in tenths of an hour, so a 1-hour 48-minute leg goes in the logbook as 1.8 and a 55-minute hop as 0.9 — airlines and insurers read those decimals, not minutes. Trucking compliance runs the same way, since hours-of-service records compare decimal on-duty totals against the federal 11-hour driving limit and 14-hour on-duty window. Paramedics, security guards and utility crews generally follow whatever their billing or scheduling software insists on, and nearly all of it insists on decimals. The pattern across all of them is identical: wherever hours meet money or legal limits, the minutes get divided by 60, and the person holding the notebook does the dividing.
Accuracy notes worth knowing
The calculator keeps four decimal places, which is finer than any payroll rounding rule — most systems round to the nearest quarter hour or the nearest tenth. When your employer rounds, a 7:52 punch may still be paid as 7.75; the exact decimal here is 7.8667, so use this page for the true value and let your payroll policy explain the difference.
Everything is computed in your browser and nothing is stored. For a whole week of entries rather than one, switch to the time card calculator, which totals seven days and multiplies by an hourly rate. For looking up single common values, the conversion chart page lists every 15-minute increment up to 12 hours.
How timesheet software shows decimal time in practice
ADP displays hours worked in two-decimal format on both the timecard screen and the pay statement. A shift punched as 8:07 and 16:38 becomes 8.52 after its rounding policy applies, and the Web Timeclock interface shows the converted figure next to the raw punch so you can spot a mismatch before approving the week. QuickBooks Time (formerly TSheets) takes the same approach inside its Timesheets grid: each daily cell holds a decimal such as 7.75, and the Who Worked report totals the column the same way, so what you see is what the payroll journal will contain.
Workday behaves a little differently. Its entered time is captured in clock notation during the week, but the Payable Time results — the numbers that flow into payroll — are decimal hours, visible in the View Payable Time panel. Knowing which screen holds which format matters, because approving the raw punches does not always reveal the rounded decimal until you open the payable view. Converting your own punches here before approval lets you predict the number Workday will produce and challenge it while the week is still editable.
Older enterprise stacks round out the picture. UKG — the company formed when Kronos and Ultimate Software merged in 2020 — computes paid hours from punch pairs and pushes the decimal result into schedules and payroll exports, and its workforce-management reports total the week in decimal columns for the same reason any spreadsheet would: the numbers add and multiply cleanly. Deputy, BambooHR and Rippling follow the same convention in their timesheet modules. The detail to check on any platform is where rounding happens — at the punch, at the day, or at the weekly total — because identical punches can produce three different decimals depending on that choice, and only the weekly-total method preserves every worked minute.
Reading the decimal hours field on a pay stub
Most US pay stubs carry a line labeled something like Regular Hours, REG HRS or Current Hours, and it is always decimal. A stub reading 80.00 means two clean 40-hour weeks; 79.92 means 79 hours 55 minutes were counted, which is where checking payslips against your own records pays off — 0.08 of an hour is under five minutes, the kind of gap created by a rounding rule or a missing punch.
Overtime usually appears on its own line as OT Hours or O.T. HRS, also in decimal, and multiplying that figure by 1.5 times your rate is the fastest sanity check on the overtime dollars above it. Some employers add a third line for double time at holiday rates. When the printed decimal does not match the hours you believe you worked, this calculator converts their figure back to minutes so you can say precisely which punch is in dispute rather than arguing over an unfamiliar decimal.
Rounding at the 40-hour overtime threshold
Rounding decisions that look harmless on a single shift change the outcome when the total lands near 40 hours. Suppose a punch comes out to 39.9833 raw (39:59 by the clock). Under a 15-minute rule that rounds to the nearest quarter hour, it becomes 40.00 and overtime applies; under a 7-minute rule — rounding to the nearest 5 minutes first — it stays just below 40 and pays entirely at straight time. The same few seconds of clock time can decide half an hour of overtime pay.
The direction of rounding matters as much as the increment. Rounding to the nearest quarter hour is generally treated as neutral, but rounding always up or always down at the threshold is what courts have penalized, because over weeks it systematically favors one side. Employees who want to check their own math can convert each daily total here, apply the employer's stated rule, and compare the sum against the stub. If the policy is not written anywhere, a short request to HR usually resolves it faster than guessing.
The regulatory basis is specific in the United States: 29 CFR § 785.48 is the Department of Labor's rounding provision, and its example is the source of the familiar 7-minute rule. Under quarter-hour rounding, time from one through seven minutes past the quarter may be dropped, and eight or more must count as a full quarter hour. The regulation's own caveat is the part worth remembering: rounding is permitted as a practical expedient, not a license, and it must average out so it does not underpay over time. Courts reading that clause have rejected schemes that only ever rounded in the employer's favor, even when each individual round was small.
24-hour clock versus AM/PM in decimal conversion
The conversion itself does not care which clock you use, but data entry does, and this is where multi-region teams lose hours. 1:15 PM typed as 1:15 into a system that expects 24-hour notation becomes 1.25 worked hours instead of 13.25 — a 12-hour error that can survive a whole pay cycle if nobody checks the daily total. Systems configured for AM/PM display convert internally, but CSV exports and API payloads frequently carry 24-hour values regardless of the interface, so a template filled in by someone in a 12-hour country can silently corrupt an import.
Teams spread across regions do best to fix one convention in the source data. Write 13:15 rather than 1:15 PM whenever the destination is uncertain, because a 24-hour value cannot be misread the way 1:15 can. Duration fields raise a related trap: 12:30 entered as a duration in a spreadsheet may be parsed as twelve and a half hours or reformatted as a time of day, depending on locale settings. Converting the intended duration to decimal (12.5) before it enters the sheet sidesteps the parser entirely, and this calculator handles that step.
Importing and exporting decimal hours between tools
Moving hours from one system to another is where decimal formats earn respect and cause damage in equal measure. A CSV export from a clock app writes 7.88 while your invoice template expects hours and minutes, and a payroll import fed raw clock strings like 7:53 may reject the file or, worse, interpret 7:53 as a date. Before any transfer, decide which side owns the conversion and keep the other in that format — one direction, one owner, no drift.
Excel and Google Sheets add their own layer, because both interpret values containing a colon as times of day and everything else as plain numbers. A cell holding 7:53 stores roughly 0.33 of a day, and multiplying it by an hourly rate gives nonsense unless you multiply by 24 first or reformat the cell. Writing the decimal (7.8833) directly into the sheet avoids the day-fraction conversion entirely, which is exactly what the converter above produces for pasting.
Overnight shifts: converting time that crosses midnight
A shift that runs from 23:00 to 07:30 is eight and a half hours on paper, yet the raw clock numbers say otherwise — subtracting 23 from 7 gives a negative. Every payroll system handles this by treating the end time as falling on the next day, which is why a punched overnight shift sometimes shows 15.5 hours or an error instead of 8.5. The safe habit is to convert each segment separately: 23:00 to 24:00 is 1.00, and 00:00 to 07:30 is 7.50, so the whole shift is 8.5 decimal hours.
Split shifts complicate it further. A nurse working 19:00 to 03:00 with an unpaid 30-minute break has 7.5 worked hours, but if the break is punched, the system must decide which day the break belongs to — some assign it to the shift start date, others split it. That choice shifts minutes across two pay days. Converting each punch to decimal here, before the week closes, shows where the system put the boundary, and it is far easier to correct a misplaced break on Wednesday than after the check clears.
Employer rounding rules on overnight and split shifts
Round-half rules interact badly with midnight. Under a nearest-quarter-hour policy, a 23:52 clock-in rounds to 23:45 (paid from 23.75), while a 00:07 clock-in rounds to 00:15 — but both roundings land on different sides of the date line, and a naive script that rounds before it resolves the day can produce a negative segment. The correct order is always resolve the date first, then round, then subtract; doing it the other way is how overnight crews end up short a quarter hour with no visible explanation.
Federal guidance treats rounding as legal only if it is neutral over time, and overnight crews have a practical way to test that: log your raw punches for two or three weeks, convert the true decimals, apply the stated rule yourself, and compare totals. A policy that shaves four minutes from every 23:50 start is small on Monday and real money by month's end. If your audit shows a consistent tilt in one direction, the raw punch record — not the rounded one — is the evidence to bring to HR or a wage claim.
Billing in six-minute increments: the lawyer's 0.1
Law firms, consultants and some agencies bill in tenths of an hour, which is why 0.1 hours equals exactly 6 minutes. The system is designed for clean multiplication — 0.3 hours at $200 is $60 — but it forces a rounding decision on every task. A call that took 14 minutes is 0.2333 exactly; billed as 0.2 it rounds down and the firm loses money, billed as 0.3 it rounds up and the client pays 22 minutes for 14. Most firm policies say to round to the nearest tenth, and timekeeping software snaps entries to the increment as you type.
The fairness question is the same one payroll faces, just at finer granularity. Six-minute rounding that is applied consistently in both directions is defensible; a habit of always rounding up on the last entry of the day is the pattern that gets bills cut in fee disputes. If you are the one being billed, converting the raw minutes to decimal yourself and multiplying by the stated rate gives you a line-item check that takes seconds — and if you are billing, doing the same math first keeps your invoices inside the increment your engagement letter promised.
Tenths spread beyond the law for the same reason: they make arithmetic legible. Accounting firms, architects and ad agencies that bill hourly typically adopt the same 0.1 grid, and time tracked in tools like Harvest or Toggl can export as either hours-and-minutes or decimal hours, with the decimal column the one that feeds invoicing. The reverse check stays the same whatever the trade: take the minutes actually spent, divide by 60, and see how far the nearest tenth sits from the exact value. A 16-minute task is 0.2667 exactly; billing it as 0.2 instead of 0.3 shifts the line by $15 at a $150 rate — and which figure is right depends on whether the policy rounds to nearest or always up.
CSV exports and the Excel [h]:mm trap
Export a CSV from any time tracker and open it in Excel, and the hours column may look fine while every formula built on it is quietly wrong. Excel stores a clock value as a fraction of a day, so 7:45 becomes about 0.3229. Display it with the hh:mm format and it reads correctly; multiply it by a rate and you get nonsense, because the sheet thinks you worked a third of an hour. The [h]:mm format is the fix for totals over 24 hours — plain hh:mm resets to zero at 24, so a 27-hour week shows as 3:00, a classic end-of-month surprise.
The reliable workflow is to keep decimals in the spreadsheet and convert only at the edges: paste decimal values from this page into the hours column, format them as plain numbers, and let SUM do the totaling. If your source data is stuck in clock notation, multiply the cell by 24 once and change its format to Number to recover true decimal hours. Google Sheets behaves the same way, so a template that works in one usually works in the other — and a template that hides this step hides it in both.
One more spreadsheet gotcha deserves its own paragraph: paste behavior. Paste 7:45 into Excel and it becomes a time — 7:45 AM — formatted as a clock and stored as 0.3229 of a day. Paste 7.75 and it stays a number. The difference stays invisible until a SUM or a VLOOKUP crosses the boundary, and it is the reason mixed-format sheets produce some rows right and some rows wrong, with errors nobody can reproduce. Decide the format before pasting, not after; if the damage is already done, a column of =A2*24 next to the suspects will show instantly which cells were parsed as times.
Decimal hours at the project level: estimating and tracking T&M work
Time-and-materials contracts live or die on the accuracy of decimal hours reported against each project code. A construction crew of four working an 8-hour 45-minute day logs 4 × 8.75 = 35.00 billable hours before overtime. If one laborer stays 37 minutes past the shift, that becomes 0.6167 additional hours, and the day total for the crew rises to 35.6167. Multiplied by a blended rate of $82 per hour, the difference between recording 8:45 and 8:37 correctly versus rounding both to 8.75 is $3.28 — trivial on one ticket, but a $1,200 annual gap on a crew that works 52 weeks.
Project management tools like Harvest, Clockify, and Monday.com all store duration in decimal hours internally and display it two ways: a timer-style HH:MM:SS for data entry and a decimal column for reporting. When a project manager pulls a budget-burn report, the tool sums the decimal column across every team member and every day. An entry logged as 1:30 appears in that sum as 1.5; an entry accidentally typed as 1.3 appears as 1.3 — thirteen minutes short of the actual time. The difference of 0.2 hours is invisible until the invoice total falls short of the contracted budget, and tracing it back to a single field requires exporting the raw CSV and checking every row.
The practical fix is to run a sanity check before submitting hours: convert each clock-notation entry here to see the decimal it should produce, then compare against what the tool recorded. A 3-hour 20-minute task is 3.3333 decimal hours; a tool that shows 3.20 has parsed it wrong — perhaps because a decimal point was typed instead of a colon, turning the minutes field into a tenths-of-hours field. Catching the error at entry takes five seconds; correcting it after the invoice is disputed takes considerably longer.
Mental math shortcuts for the five most common clock times
Most payroll and billing situations repeat the same handful of time values, and knowing their decimal equivalents cold makes the weekly close much faster. Here are the five that appear most often, with the arithmetic behind each. Fifteen minutes is exactly 0.25 because 15 ÷ 60 = 0.25 — one quarter of an hour. Thirty minutes is 0.50 (half an hour). Forty-five minutes is 0.75 (three quarters). Ten minutes is 0.1667, which rounds to 0.17 or 0.2 depending on the precision your payroll system uses. Twenty minutes is 0.3333, rounding to 0.33.
The anchor that unlocks everything else is the six-minute rule: every six minutes of clock time equals exactly 0.1 decimal hours. That relationship — six minutes per tenth — is why legal billing uses six-minute increments and why pilots log in tenths. Thirty-six minutes is 0.6, forty-two is 0.7, forty-eight is 0.8, fifty-four is 0.9. Any time with minutes that are a multiple of six converts in your head instantly. For everything else, round the minutes to the nearest six-minute mark to get a quick estimate, then use the calculator to confirm the exact value.
Two worked examples show the method in practice. A shift from 9:00 to 17:22 runs 8 hours and 22 minutes. Twenty-two minutes is between 18 (0.3) and 24 (0.4). Divide 22 by 60 to get 0.3667, so the shift is 8.3667 hours — a payroll system rounding to the nearest tenth records 8.4, and one rounding to the nearest quarter-hour records 8.25 or 8.5 depending on the rule. A second shift from 7:45 to 15:15 runs exactly 7 hours and 30 minutes: 30 ÷ 60 = 0.5, giving 7.5 decimal hours with no rounding needed. If you can hold those two anchor values — 0.25 per quarter-hour and 0.1 per six minutes — you can cross-check almost any entry before it reaches the system.