The moment a simple time formula returns 0.17 instead of 4.0, the spreadsheet stops being a tool and starts being a puzzle with missing pieces. That's exactly where this user landed, and their frustration is entirely justified. The numbers are right, the formatting looks right, and yet the output makes no sense. This isn't a failure of math; it's a failure of context. The spreadsheet is not showing its work, and when that happens, even experienced users start questioning their own competence.
Here's what's actually going on: the formula is subtracting two date-time values, and the result is being interpreted as a fraction of a day. A time span of four hours is roughly 0.17 when expressed as a proportion of a 24-hour day. The user set the cell to a Number format, which is why they see 0.17 instead of 4:00. The spreadsheet isn't wrong; it's just using a different unit of measure than the one the user expects. This is the kind of thing that trips people up because the interface gives no hint that the underlying value is a decimal fraction of a day. The user did everything right, checked the formats, verified the dates, and still hit a wall. That's not a lack of effort; it's a lack of transparency in the tool itself.
The practical takeaway here is that spreadsheets treat time as a portion of a day, not as hours and minutes. When you subtract two times, you get a decimal that represents that fraction. To display it as hours, you need to multiply by 24 and format the result as a number, or keep the result in a time format and let the spreadsheet handle the conversion. The fix is simple, but the discovery is not. This user had to post online, wait for responses, and sift through explanations to figure out what should have been obvious from the start. That's a failure of design, not a failure of the user.
This is exactly why we push for tools that surface the logic behind the numbers. A spreadsheet should not make you guess whether a result is in hours, days, or fractions of a day. It should tell you. The user's confusion is not a sign of weakness; it's a signal that the interface is not doing its job. When you have to know the internal representation of a value just to interpret a basic subtraction, the tool is getting in the way of the work. The solution is not to memorize every quirk; it's to demand better explanations from the software you use. Until then, the workaround is simple: multiply by 24, label your units, and remember that 0.17 is not wrong, it's just not what you asked for.