What the calculator assumes
It applies the registry maximums for a generic top-level domain: up to forty-five days of auto-renew grace, thirty days of redemption, five days of pending delete, then release. Those are boundaries, not a schedule. The registry permits that much time; the registrar decides how much of it to use, and many delete considerably earlier, which pulls every subsequent date forward with it.
So the output is a latest-possible sequence. If a record already shows
redemptionPeriod, the first window is over regardless of what the arithmetic from
the expiry date suggests, and the status code is the better evidence. The
domain lifecycle page sets out each window in
full, with the code that identifies it.
Why the status code beats the arithmetic
Three of the five windows are indistinguishable from the outside: once delegation is withdrawn the name resolves to nothing, and it resolves to nothing whether it is in redemption, in pending delete, or simply on hold. Only the registration record distinguishes them, and it does so through the status field. Calculate the windows to know what is possible; read the status to know where the name actually is.
The one exception is pending delete, which is fixed at five days and is therefore the only reliable countdown in the whole process. If a record shows that code, the release date is knowable to within a day, and that is as precise as this gets.
Why the registrar matters more than the registry here
The registry sets the outer boundaries and the registrar decides what actually happens inside them, which is why two names expiring on the same day at different registrars can behave nothing alike. One may carry a name for the full auto-renew grace period, notifying the holder throughout. Another may delete it after a fortnight. A third may not let it proceed at all, and instead sell the expiring registration through its own auction platform.
That last route removes a name from this sequence entirely, and it is worth understanding because it is where anything commercially valuable tends to go. A registration sold at a registrar auction is transferred to the buyer directly: it never enters redemption, never reaches pending delete and never appears in a drop list. The registry record shows a transfer rather than a new creation, so from the outside it looks like an ordinary change of registrar rather than a change of owner.
The practical consequence for anyone reading dates is that the arithmetic below describes the slowest possible path, and the slowest possible path is the least likely one for a name anybody wants. Treat the output as a boundary, read the status code for the truth, and expect the interesting names to leave the process early.
What happens at release
The name returns to the available pool in a registry batch operation, and for any extension with real demand that moment is contested by automated buyers submitting registrations in volume. A name with residual value very rarely sits unregistered afterwards for long enough to be noticed, which is a useful reality check: finding one that has usually means its value is not what it appears.
Afterwards the registry record resets. A new registration carries a new creation date and a new handle, and loses the previous ones entirely, which is why a name with a decade of inbound citations can show a creation date of last week. The whois record page covers how to read that, and the field decoder will name the dates in a record you already have.
