Two clocks, one stopwatch
There are two different questions hiding inside "how long between these two times", and they give different answers several times a year.
The first is the wall clock question. Take the digits written on the two stamps, subtract them as if the calendar were a ruler, and you get a number. Noon Saturday to noon Monday is two days, forty-eight hours, no argument.
The second is the stopwatch question. How much time actually passed? If a daylight saving change fell in the middle, the answer is forty-seven hours, or forty-nine, because one civil day was short or long. This page computes from epoch milliseconds, which is the stopwatch answer, and then shows you the wall clock answer beside it and the size of the gap between them. When they disagree it names the day that caused it.
Neither answer is the correct one in general. A rental agreement that says "two days" almost certainly means the wall clock. A service level agreement measured in hours almost certainly means the stopwatch. Pick deliberately.
Why the offset is looked up and not assumed
Nowhere in this tool is a time zone stored as a number of hours. Zones are stored as IANA identifiers such as America/New_York, and the offset is resolved from the browser database for the instant in question. New York is five hours behind UTC in January and four hours behind in July. A tool holding "New York equals minus five" is right for roughly eight months a year and quietly wrong for the rest, and it is wrong in the direction that makes meetings start an hour late.
The same lookup is what makes the two-zone mode honest. If you record a start in Berlin and an end in Chicago, both are converted to real instants before anything is subtracted, so the offset difference is already inside the answer. The zone table at the bottom shows both offsets so you can check that the conversion did what you expected — and it is worth checking, because a stamp entered in the wrong zone produces a plausible-looking wrong answer rather than an error. If you only want to see one moment expressed in several places, the time zone converter does that without any subtraction.
The years, months and days line is a convention, not a measurement
The elapsed figure in hours is a fact. The line reading "1 year, 2 months, 5 days" is a convention, because months are not a fixed length and the answer depends on the order you consume the units in and on what you do when the day of the month does not exist in the target month.
The rule used here: count whole months forward from the earlier stamp, clamping the day to the last valid day of the month when it overflows, then measure whatever is left in days, hours and minutes. Under that rule January 31 plus one month is February 28, or February 29 in a leap year. The alternative rule lets the overflow spill, making it March 3. When the clamp fires, the output says so and shows you what the other convention would have produced, because the difference is not a rounding error — it can change the whole-month count by one.
February 29 gets its own note for the same reason. An anniversary of a leap day exists in one year out of four. This page clamps it to February 28 in common years; other systems use March 1. On an age boundary that single day decides whether somebody has had a birthday yet. There is no arithmetic that settles it, only a stated policy, and the honest thing is to write the policy down. The age and milestone checker takes the same position from the birthday side.
What this page does not try to know
It does not know your working hours, so an eighteen-hour gap is eighteen hours whether or not anybody was awake for them. For elapsed time measured only inside a working window, use the business hours duration calculator, which takes a schedule and a holiday list you supply yourself.
It also does not know whether the wall clock time you typed actually existed. In the hour that a spring-forward transition deletes, the local clock never reads 02:30, and the conversion has to land somewhere; it lands on the instant immediately after the jump. Enter a stamp inside a deleted hour and the offset shown in the table will not match what you typed — that mismatch is the signal. To find out exactly where those deleted and repeated hours fall for a given zone, run the daylight saving change dates page for that year.
Everything is computed in the page. The timestamps you type are not sent anywhere, which matters when the thing you are measuring is an incident window out of a production log.
Questions people ask
Why does it say 47 hours when the calendar clearly shows two days?
Because a daylight saving change fell inside the span and one civil day was only 23 hours long. Both numbers are correct answers to different questions: the calendar is counting days, the stopwatch is counting hours. The output shows both, along with the name of the day that ran short, so you can quote whichever one your question actually needs.
Can the two timestamps be in different time zones?
Yes. Set the end zone to something other than "the same zone as the start" and both stamps are converted to real instants before subtraction. The offset difference is then already included in the result — a common mistake is to compute the difference and then subtract the zone gap a second time, which doubles the error.
How does it handle a start date of February 29?
It clamps the anniversary to February 28 in common years and says so in the output. That is a stated policy rather than a fact; some systems use March 1 instead. The difference only matters at an anniversary boundary, but there it can move a whole-year count. If your organisation has a written rule, follow that one and treat this output as a cross-check.
What happens if I enter a time that never existed?
During a spring-forward transition the local clock skips an hour, so a stamp inside that hour has no matching instant. The conversion resolves to the moment just after the jump, and the offset shown in the two-instants table will not be the one you would have expected for that reading. Treat a mismatch there as a sign that the input needs rewriting.
Does anything get uploaded?
No. The arithmetic and the time zone lookups both run in your browser using data the browser already ships with. Nothing is transmitted, logged or stored.