Nice little tool, and the decimal-conversion pain is real. Two things from the spreadsheet side and one from the code, offered because they might be biting you rather than as nitpicks.
On the spreadsheet premise: Excel actually does handle this correctly, and the failure is usually one of two specific mistakes rather than a limitation. Excel stores time as a fraction of a day, so 7:45 typed as 7:45 is stored as 0.322916..., and the sum of a column of those is exact. The two traps are (a) typing 7.45 instead of 7:45, which enters a number and not a time, and (b) formatting the total as h:mm instead of [h]:mm. The square brackets are the whole game: without them Excel wraps at 24 hours, so a 25-hour week displays as 1:00 and people conclude the spreadsheet is broken. Decimal hours is then just =A1*24. Worth knowing because it makes your tool the convenience it is, rather than a workaround for something Excel cannot do.
On the snippet, the one I would fix first: if hours and minutes come from input elements, .value is a string, and isNaN("7") is false so the guard lets it through. Then "7" + (45/60) is string concatenation, and you get "70.75" instead of 7.75. Number(hours) + Number(minutes)/60, or reading valueAsNumber, closes it. isNaN also lets null through, since Number(null) is 0; Number.isFinite on the coerced values is a tighter guard.
And for payroll specifically: hours + minutes/60 gives binary floats that do not round-trip, so 7 h 10 m becomes 7.166666666666667. Sum a month of those, multiply by an hourly rate, and you can land a cent away from what a human gets with a calculator. The usual fix is to keep everything in whole minutes as integers all the way through and convert to money once, at the end, rounding exactly once. It is invisible on one shift and it is exactly the thing an accountant notices at the end of the quarter.
Nice little tool, and the decimal-conversion pain is real. Two things from the spreadsheet side and one from the code, offered because they might be biting you rather than as nitpicks.
On the spreadsheet premise: Excel actually does handle this correctly, and the failure is usually one of two specific mistakes rather than a limitation. Excel stores time as a fraction of a day, so 7:45 typed as 7:45 is stored as 0.322916..., and the sum of a column of those is exact. The two traps are (a) typing 7.45 instead of 7:45, which enters a number and not a time, and (b) formatting the total as h:mm instead of [h]:mm. The square brackets are the whole game: without them Excel wraps at 24 hours, so a 25-hour week displays as 1:00 and people conclude the spreadsheet is broken. Decimal hours is then just =A1*24. Worth knowing because it makes your tool the convenience it is, rather than a workaround for something Excel cannot do.
On the snippet, the one I would fix first: if hours and minutes come from input elements, .value is a string, and isNaN("7") is false so the guard lets it through. Then "7" + (45/60) is string concatenation, and you get "70.75" instead of 7.75. Number(hours) + Number(minutes)/60, or reading valueAsNumber, closes it. isNaN also lets null through, since Number(null) is 0; Number.isFinite on the coerced values is a tighter guard.
And for payroll specifically: hours + minutes/60 gives binary floats that do not round-trip, so 7 h 10 m becomes 7.166666666666667. Sum a month of those, multiply by an hourly rate, and you can land a cent away from what a human gets with a calculator. The usual fix is to keep everything in whole minutes as integers all the way through and convert to money once, at the end, rounding exactly once. It is invisible on one shift and it is exactly the thing an accountant notices at the end of the quarter.