Duration begins with two complete date-times
An elapsed time duration is ending timestamp minus starting timestamp. Each timestamp must identify a date and clock time under the same interpretation. NumUtility reads both `datetime-local` fields through the browser's device-local environment, subtracts their millisecond values, preserves whether the difference is forward or negative, and decomposes the absolute magnitude into complete 24-hour days, remainder hours, minutes, and seconds. The visible unit fields are a quotient-and-remainder display of one continuous difference.
A local date-time field contains no explicit zone name or UTC offset. The browser applies the device's configured rules when converting it to a timestamp. That makes the calculator useful for two readings intended in the same local environment, but it cannot prove the device clock is correct or independently compare New York with London. Record the zone assumption whenever another person must reproduce the result.
Same-day subtraction
Input: June 10, 2026 09:35 to June 10, 2026 14:20. Rule: subtract end minus start in the same local offset. Process: 09:35 to 14:00 is 4 hours 25 minutes, then 20 minutes reaches 14:20. Result: Forward, 0 days, 4 hours, 45 minutes, 0 seconds; Total hours 4.75. Interpretation: identical calendar dates can still contain a substantial timestamp duration.
Input: June 10, 2026 14:20 to June 10, 2026 09:35. Rule: retain the sign instead of reordering inputs. Process: the magnitude is the same 4 hours 45 minutes, but end minus start is below zero. Result: Negative, 0 days, 4 hours, 45 minutes. Interpretation: unlike Date Difference, Time Duration communicates that the entered ending timestamp precedes the start.
Crossing one or several dates
Input: May 1, 2026 22:45 to May 2, 2026 01:15. Rule: use complete dates before subtracting clock readings. Process: 75 minutes reach midnight and another 75 minutes reach 01:15. Result: 2 hours 30 minutes. Interpretation: subtracting 01:15 − 22:45 as bare clock faces would create the wrong negative answer.
Input: September 10, 2026 18:30 to September 12, 2026 07:00. Rule: count continuous time, then decompose. Process: 5 hours 30 minutes reach midnight, 24 hours cover September 11, and 7 hours reach the end. Result: 1 displayed complete day, 12 hours, 30 minutes, or 36.5 total hours. Interpretation: the Days field contains complete 24-hour blocks, not named dates touched.
DST and zone limits
A local day can contain 23 or 25 elapsed hours where clocks change. Input: midnight before to midnight after a spring transition in a locality that advances one hour. Rule: resolve each local reading using the applicable offsets. Process: the skipped hour reduces the timestamp difference. Result: 23 elapsed hours, although the calendar dates are adjacent. Interpretation: this example depends on the stated place, year, and current time-zone data.
NIST documents US transitions and exceptions, while IANA maintains changing rules for representative locations worldwide. The calculator delegates interpretation to the device and accepts no named-zone selector. If both entered readings are merely wall times from different zones, the result is not a valid international comparison. Convert each to a verified instant first or use software that accepts named zones and current rules.
What the calculator includes and omits
The output shows direction, complete days, remainder hours, minutes, seconds, and decimal Total hours. Seconds are normally zero because the current form accepts minutes, but the underlying breakdown supports them. Equal timestamps produce zero in every field. Invalid or empty values show a validation message. The calculator does not calculate calendar years or months because those are variable-length units.
It also does not subtract meal breaks, sleep, weekends, working hours, pauses, travel stops, or equipment downtime. It does not know which clock reading is official, whether an ambiguous repeated DST hour means its first or second occurrence, or whether a nonexistent local time was normalized by the browser. For payroll, transport, contracts, visas, legal deadlines, or safety records, use the governing system and its approved time source.
Checks and common mistakes
Common mistakes include omitting the date, mixing AM and PM, assuming an earlier ending clock always means next day, treating Days as calendar dates, and changing a negative result to positive without documenting why. Another is claiming two local readings are in one zone when one came from an organizer elsewhere. Preserve the raw inputs before correcting them.
Check by rebuilding the end: add the signed Total hours to the resolved start and confirm the same instant. Independently convert hours to minutes for small examples. For 36.5 hours, 36.5 × 60 = 2,190 minutes; subtracting the components gives 1 × 1,440 + 12 × 60 + 30 = 2,190. If the check fails near a clock change, inspect the actual offsets rather than adding or removing an hour by guesswork.
Borrowing manually without losing the date
For a manual calculation with unchanged offset, write the end above the start and borrow through seconds, minutes, hours, and dates. If 10 end minutes cannot subtract 45 start minutes, borrow one hour as 60 minutes. If the ending hour then cannot subtract the starting hour, borrow one calendar date using that actual date's local length only for ordinary wall-clock arithmetic. Timestamp subtraction is safer around DST because the borrowed local day may not contain 24 elapsed hours.
Example: August 4 16:50 to August 5 09:10. Borrowing makes the end 33:10 relative to the starting date; 33:10 − 16:50 = 16 hours 20 minutes. Rebuild the end by adding 16 hours 20 minutes to the start. This second route catches an incorrect borrow while preserving the correct date change.
Precision, rounding, and timestamp evidence
The interface accepts minute precision, so an observed event at 09:35:40 cannot be represented exactly without rounding or truncation before entry. State that loss rather than presenting zero seconds as measured precision. Total hours is rounded for display by the site's number formatter; the component fields derive from whole seconds after millisecond magnitude is floored. For high-resolution experiments, logging, or billing rules, use a system designed for the required precision.
A screenshot of the result does not preserve device zone, clock synchronization, browser parsing behavior, or source records. When the duration matters later, save ISO-formatted timestamps with explicit offsets, the named zone when applicable, and the calculation date. This evidence distinguishes arithmetic mistakes from later rule changes or device configuration differences.
Choosing duration rather than calendar difference
Use continuous duration when a machine ran, a recording played, or an event occupied actual time. Use calendar difference when the question asks how many named dates, completed months, or anniversaries separate inputs. A span can be one date-only day but 23 elapsed hours at a spring transition, or one calendar month with 28 through 31 date-only days. Those are not competing answers.
If a result will feed speed, rate, or utilization, convert the continuous timestamp difference into one consistent unit before division. Do not insert calendar months as though they were fixed hours. If the question instead groups work by local calendar dates, retain those dates and use the schedule's explicit day boundaries rather than replacing them with elapsed 24-hour blocks.