Working hours between two datetimes
A ticket opened at 15:00 UTC on Friday, July 24, 2026 and closed at 11:30 on Monday, July 27 took 4.5 working hours, or 270 minutes. Weekend time and hours outside the daily window are left out, which suits support targets and incident reports. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Start datetime
- 2026-07-24T15:00:00Z
- End datetime
- 2026-07-27T11:30:00Z
- Working seconds
- 16,200
- Working minutes
- 270
- Working hours
- 4.5
- Workday start
- 09:00
This working-hours calculator measures only the portions of an explicit datetime interval that fall inside a daily UTC business window from Monday through Friday. Choose the default 09:00–17:00 window or supply another same-day window. The response gives exact working seconds plus convenient minute and hour totals, making the result useful for service targets, elapsed-business-time reports, and reproducible automation.
Define the interval and business window precisely
Requiring a timezone removes a common source of silent errors: a bare local timestamp can mean different instants on different machines. The start is inclusive and the end is exclusive, which makes consecutive calculations composable without counting a boundary twice. Overnight shifts are deliberately rejected rather than assigned an ambiguous weekday.
The interval may begin before the window, inside it, after it, or on a weekend. Only actual overlap contributes. A Friday interval can therefore contribute its remaining Friday hours, ignore all of Saturday and Sunday, and resume at the Monday opening time.
Public holidays are not inferred because holiday calendars differ by country, region, industry, and employer.
Use the result in operational workflows
Support teams can measure the business time consumed by a ticket without charging overnight or weekend hours against an internal target. Operations teams can compare incident acknowledgement and recovery intervals on one shared clock, even when the source timestamps carry different offsets. Finance and professional-services teams can turn timestamped activity into reviewable working-hour totals before applying their own billing rules.
If your policy includes public holidays, regional weekends, lunch breaks, rotating shifts, daylight-saving local windows, or overnight schedules, apply those policies in a separate calendar-aware layer rather than assuming this calculator knows them. Its narrow contract is an advantage: it provides a transparent Monday-to-Friday UTC baseline that is easy to test, sum, compare, and explain to reviewers.
What you can do with it
Support SLA measurement
Count only weekday business-window time between ticket creation and resolution timestamps.
Incident duration reporting
Normalize offset-bearing event timestamps to one UTC schedule and exclude weekend downtime.
Auditable service-hour totals
Generate deterministic working seconds for later billing or compliance rules without hidden locale behavior.
FAQ
Which days are excluded?
Saturday and Sunday in UTC are excluded. Public holidays and regional weekend patterns are not included.
Does the business window follow daylight saving time?
No. The daily window is explicitly UTC, so it remains stable and does not shift with daylight-saving rules.
Can I define an overnight business window?
No. The window must open and close on the same UTC day, with the end later than the start.
Is the end time included in the count?
No. The start moment counts and the end moment does not, so you can add up back-to-back intervals, such as one per shift or per day, without counting the boundary twice.
Do the date-times need a time zone?
Yes. Each one must carry a UTC marker or an explicit offset. A bare local time can mean different moments on different computers, so the calculator refuses to guess and converts everything to UTC.
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/working-hours-between \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"start_datetime":"2026-07-24T15:00:00Z","end_datetime":"2026-07-27T11:30:00Z"}'const res = await fetch("https://api.kit.forhosting.com/date/working-hours-between", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"start_datetime": "2026-07-24T15:00:00Z",
"end_datetime": "2026-07-27T11:30:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/working-hours-between",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"start_datetime": "2026-07-24T15:00:00Z",
"end_datetime": "2026-07-27T11:30:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/working-hours-between", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"start_datetime":"2026-07-24T15:00:00Z","end_datetime":"2026-07-27T11:30:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"start_datetime":"2026-07-24T15:00:00Z","end_datetime":"2026-07-27T11:30:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/working-hours-between", 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_datetime": "2026-07-24T15:00:00Z",
"end_datetime": "2026-07-27T11:30:00Z"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.working_hours_between",
"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.
Limits
max_span_days | 36600 |
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
It accepts timezone-qualified ISO datetimes, converts both endpoints to UTC using deterministic calendar arithmetic, and excludes every Saturday and Sunday.
Define the interval and business window precisely
Send `start_datetime` and `end_datetime` as complete ISO datetimes that include either `Z` or an explicit numeric UTC offset. The recurring business window defaults to 09:00 through 17:00 UTC, and you may change it with `workday_start` and `workday_end` in strict 24-hour `HH:MM` form. Both window endpoints belong to the same UTC calendar day, so the end must be later than the start.
Understand the deterministic UTC calculation
Each supplied offset is converted to a UTC instant using integer arithmetic over the proleptic Gregorian calendar. Monday through Friday receive one candidate window; Saturday and Sunday receive none. For every weekday, the calculator intersects the requested interval with that day's opening and closing instants and adds a positive overlap in seconds. This approach handles partial first and last days without special guesses and makes offset-bearing inputs equivalent when they identify the same UTC instant. The implementation does not construct a JavaScript `Date`, read the system clock, consult locale settings, contact a timezone service, use randomness, or access the network. It then visits the bounded set of UTC calendar days touched by the interval. The response repeats the effective window and reports `timezone` as `UTC`, making the assumptions visible in stored audit records instead of hiding them in server configuration. Equal endpoints correctly produce zero; an end before the start is rejected.
Use the result in operational workflows
In automation, store the original endpoints, chosen UTC window, and returned integer seconds together; that record can be replayed later and will produce the same answer because the capability has no dependency on today's date, a machine timezone, or a changing external calendar. The browser path is useful for one-off checks, while the API path costs $0.002 per successful request and supports repeatable pipelines.
Technical questions
What does it cost?
The API price is $0.002 per successful request, and the same pure calculation can run in the browser.
Can the input datetimes use UTC offsets?
Yes. Use `Z` or an explicit offset such as `-04:00`; each endpoint is normalized to its UTC instant.