Midnight requires the date
When an ending clock reading is smaller than the starting reading, the interval may cross midnight, span several dates, or truly be negative. Clock faces alone cannot choose among those possibilities. Attach the intended calendar date to both readings first. The general rule remains ending timestamp minus starting timestamp; “add 24 hours” is only a shortcut for one ordinary overnight crossing with no offset change.
Use 24-hour notation or include AM/PM unambiguously. Midnight at the beginning of May 2 is May 2 00:00, not May 1 24:00 in NumUtility's input. Noon is 12:00 PM; midnight is 12:00 AM. Writing the date beside both values prevents a common twelve-hour error and makes multi-night intervals possible.
The standard 22:30 to 01:15 example
Input: May 1, 2026 22:30 to May 2, 2026 01:15. Rule: subtract complete date-times. Process: 1 hour 30 minutes reaches 00:00, then 1 hour 15 minutes reaches 01:15. Result: 2 hours 45 minutes. Interpretation: the smaller ending clock is later because its date is the following day.
Input: May 1, 2026 10:30 PM to May 2, 2026 1:15 AM. Rule: convert AM/PM correctly before subtraction. Process: 10:30 PM becomes 22:30 and 1:15 AM becomes 01:15 on May 2. Result: the same 2 hours 45 minutes. Interpretation: AM/PM notation changes presentation, not the underlying instants when converted correctly.
More than one midnight
Input: July 3, 2026 23:00 to July 6, 2026 02:30. Rule: retain every date rather than assuming one overnight cycle. Process: 1 hour reaches July 4, two complete dates contribute 48 hours, and 2 hours 30 minutes reach the end. Result: 2 days, 3 hours, 30 minutes, or 51.5 total hours. Interpretation: adding 24 once would undercount by a full day.
For long spans, separate the first partial day, intervening complete elapsed blocks, and final partial day only as a manual check. Let timestamp subtraction remain the primary calculation. Calendar dates touched are not the same as complete days; this example touches four date labels but contains only two complete 24-hour blocks plus a remainder.
A negative result may be correct
Input: May 2, 2026 01:15 to May 1, 2026 22:30. Rule: preserve entered order. Process: end minus start is −2 hours 45 minutes. Result: Negative with magnitude 2 hours 45 minutes. Interpretation: do not automatically assume the user forgot to advance the end date; the records may genuinely be reversed.
If two times are intended as a repeating daily schedule and no dates were recorded, adding a day to an earlier ending clock is an assumption, not recovered evidence. State that assumption explicitly. For attendance, transport, equipment, medical, or official records, obtain the original dated log rather than repairing it silently.
DST transition nights
An ordinary 22:30 to 01:15 span is 2 hours 45 minutes only when the UTC offset remains unchanged. If a regional transition occurs inside the interval, the elapsed duration can differ from wall-clock subtraction. A spring gap removes an hour; an autumn repetition adds one and can make a repeated clock reading ambiguous.
The calculator uses the device's local rules and provides no named-zone or repeated-hour selector. Verify the locality, date, and offsets with an authoritative source for transition nights. A fixed statement that every night is twenty-four hours is not globally reliable, and US transition dates should not be generalized to Canada, the UK, Australia, or other regions.
Tool boundaries and verification
NumUtility requires two full local date-times, reports signed elapsed components and Total hours, and does not infer an omitted date. It does not accept `24:00`, named zones, flight arrival zones, breaks, or shift premiums. It is a duration calculator, not a work-rule or transport timetable interpreter.
Verify a normal overnight result by splitting at midnight and adding the two portions. Check the sign and date labels before changing inputs. For multi-day intervals, convert every component to minutes and compare with Total hours × 60. Near DST, verify resolved UTC offsets. Common errors are losing the next-date change, reversing AM/PM, adding 24 to a multi-night interval, and treating a browser-normalized nonexistent time as authoritative.
Twelve-hour notation failure modes
The sequence 11:30 PM to 12:15 AM crosses midnight and lasts 45 minutes, not 12 hours 45 minutes. In twelve-hour notation, the hour after 11 PM is 12 AM on the next date. Similarly, 11:30 AM to 12:15 PM is a same-date 45-minute interval. Writing AM or PM on both endpoints and converting to 24-hour form before subtraction prevents the labels around twelve from being reversed.
Input controls show locale-dependent presentation, but their stored local value follows a normalized date-and-time format. Do not infer an omitted AM/PM from appearance or copy only the time portion into notes. Save the full date alongside it, especially for logs that contain many overnight entries.
Overnight records with breaks
A continuous interval and active time are different quantities. An overnight shift from 20:00 to 04:00 is eight elapsed hours under unchanged offset. If it contains a 30-minute unpaid break, active time is seven hours thirty minutes only after that verified break is subtracted. NumUtility reports the uninterrupted eight hours because it has no break fields.
Do not use a general subtraction page to determine wages, regulated rest, overtime, or employment compliance. Those questions can specify rounding, paid breaks, DST treatment, and local law. Record each start, stop, and applicable rule in the approved system. This guide explains clock arithmetic, not entitlement.
Testing overnight software
A reliable test set includes 22:30 to next-day 01:15, equal timestamps, reversed endpoints, a two-midnight span, a month-end crossing, a year-end crossing, and both DST transition types in a named zone. Check both component output and Total hours. Month and year labels should not change ordinary elapsed arithmetic, while actual offset changes should.
Also test invalid input and a future end paired with a past start. If software silently adds one day whenever the ending clock is smaller, the reversed case will expose the defect. If it always assumes 24-hour dates, transition-night cases will expose that defect. Keep expected offsets with the test data so future time-zone database updates can be distinguished from regressions.
Month-end and year-end crossings use exactly the same complete-timestamp rule. Input: December 31, 2026 23:50 to January 1, 2027 00:20 under an unchanged offset. Rule: subtract the dated instants. Process: ten minutes reach midnight and twenty minutes follow it. Result: 30 minutes, not one year or one day. Interpretation: calendar labels changed while little continuous time passed. A comparable February 28 crossing can include February 29 in a leap year, but the number of elapsed hours still comes from timestamps rather than the number of month labels. When documenting recurring overnight work, store an explicit end date for every occurrence. A convention such as “end times before 06:00 belong to the next day” may be useful in one organization, but it is a data-entry rule that must be stated, not a universal property of clocks. If an overnight record spans separate time zones—such as travel—resolve each endpoint in its own named zone before subtraction; treating both as the device zone can produce a plausible but false duration.