Time elapsed percentage calculator
Enter a start, an end and a moment to check, and see how far through the interval it is: 14:00 in a window from 08:00 to 20:00 UTC is 50% of the way. Nothing depends on the current clock. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Start
- 2026-07-25T08:00:00Z
- End
- 2026-07-25T20:00:00Z
- Reference
- 2026-07-25T14:00:00Z
- Progress percent
- 50
- Elapsed ms
- 21,600,000
- Duration ms
- 43,200,000
- Reference relation
- within
This time elapsed percentage calculator measures progress through an explicit interval without consulting the current clock. Provide a start datetime, an end datetime, and the reference instant you want to evaluate. Every value must include Z or a numeric UTC offset, so equivalent instants produce the same answer regardless of the computer or browser running the calculation. The result includes the rounded, clamped percentage plus the signed elapsed milliseconds, total duration, clamp status, and the reference position relative to the interval.
Define a complete interval and reference instant
Progress is meaningful only when its boundaries and observation point are unambiguous. Supply start, end, and reference as full ISO 8601 datetimes with seconds and either Z or an explicit numeric UTC offset. The end must represent an instant later than the start after both offsets are normalized.
The reference may fall inside the interval, before it, or after it. This makes the calculator useful for historical checks, scheduled milestones, countdowns, service windows, and reproducible tests because it never substitutes the machine clock. A datetime such as 2026-07-25T14:00:00Z is explicit, while a local timestamp without an offset is rejected.
Offset forms can describe the same instant: 2026-07-25T16:00:00+02:00 and 2026-07-25T14:00:00Z are equal here. Calendar fields are validated before conversion, including month length and Gregorian leap-year rules, so impossible dates do not silently roll into another day.
Understand the UTC calculation and clamping
The calculation first converts each supplied datetime into the same UTC millisecond scale. It subtracts start from end to obtain the complete duration and subtracts start from reference to obtain signed elapsed time. The raw percentage is elapsed divided by duration, multiplied by one hundred.
By default, the returned percentage is clamped between zero and one hundred: a reference before the start reports zero, and one after the end reports one hundred. You may provide different minimum and maximum percentages when another bounded scale is required, as long as the maximum is not lower than the minimum.
What you can do with it
Measure a release window
Calculate a stable progress percentage for a deployment or maintenance interval at an explicitly recorded checkpoint.
Reproduce a dashboard value
Save the reference instant with an interval and regenerate exactly the percentage that a user previously saw.
Test boundary behavior
Verify before-start, in-range, and after-end states with configurable clamp limits and deterministic expected output.
FAQ
Does it use the current time?
No. You must provide reference explicitly, and the calculation never reads a clock.
Are timezone offsets supported?
Yes. Use Z or a numeric offset such as +02:00 or -05:30; every input is normalized to UTC.
Can start and end be equal?
No. End must be later than start because a zero-length interval has no defined elapsed percentage.
What if the moment is before the start or after the end?
By default the percentage stops at 0 before the start and at 100 after the end. The elapsed time keeps its sign, so you still see how far outside the interval the moment lies.
How many decimals does the percentage have?
Six by default. You can choose anywhere from zero to twelve decimal places, and rounding happens only after the percentage has been held within its limits.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/date/time-progress-percent \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"start":"2026-07-25T08:00:00Z","end":"2026-07-25T20:00:00Z","reference":"2026-07-25T14:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/date/time-progress-percent", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"start": "2026-07-25T08:00:00Z",
"end": "2026-07-25T20:00:00Z",
"reference": "2026-07-25T14:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/time-progress-percent",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"start": "2026-07-25T08:00:00Z",
"end": "2026-07-25T20:00:00Z",
"reference": "2026-07-25T14:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/time-progress-percent", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"start":"2026-07-25T08:00:00Z","end":"2026-07-25T20:00:00Z","reference":"2026-07-25T14:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"start":"2026-07-25T08:00:00Z","end":"2026-07-25T20:00:00Z","reference":"2026-07-25T14:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/time-progress-percent", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"start": "2026-07-25T08:00:00Z",
"end": "2026-07-25T20:00:00Z",
"reference": "2026-07-25T14:00:00Z"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.time_progress_percent",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Understand the UTC calculation and clamping
Clamping affects progress_percent only; elapsed_ms remains signed and therefore preserves how far the reference lies before or beyond the interval. The clamped field tells you whether bounding changed the raw value, while reference_relation reports before, within, or after. An instant exactly on either boundary is considered within the interval and naturally produces its corresponding endpoint percentage.
Choose precision and use deterministic results
The implementation does not read the network, use randomness, call Date, or inspect a host timezone. Store the exact reference alongside a computed result if the calculation needs to be reproduced later. If your application wants live progress, generate the reference explicitly at its own boundary and send that value; the capability deliberately remains a pure calculation rather than hiding a clock read. Use precision to select from zero through twelve decimal places for progress_percent; the default is six. Rounding happens only after the raw percentage has been bounded, which keeps the selected clamp endpoints authoritative. The duration_ms and elapsed_ms fields stay as integer millisecond differences, so consumers can audit the percentage or present a separate duration. Its Gregorian conversion is arithmetic, which means the same valid request yields the same JSON in a server Worker and in a visitor's browser.
Technical questions
What does it cost through the API?
Each request costs $0.002. The same pure calculation can also run in the browser.
What happens when the reference is outside the interval?
The percentage is constrained to the configured clamp range, while signed elapsed_ms and reference_relation preserve its actual position.