Skip to content
AZ Tools

Add Business Hours to a Date

Add N working hours to a start datetime — skip weekends and holidays, respect a per-day work window, get the landing timestamp and a per-day breakdown.

Working days
End datetime
2026-10-20 17:00
Per-day breakdown · Total: 16 h / 2 d
DayHours used
2026-10-198.00 h
2026-10-208.00 h

Holidays are an explicit list — country calendars vary, so paste yours. Sub-day starts that fall mid-window are honored exactly.

How to use

  1. Set the start datetime (defaults to now) and the work hours to add.
  2. Configure your work window (default 9–17), toggle weekends, and paste any holidays as YYYY-MM-DD per line.
  3. Result is the landing timestamp; the breakdown below shows the per-day split.

About this tool

Show

Answers "if I start now and burn N working hours, when am I done?" — useful for SLA targets, ticket due dates, or planning effort that has to fit between 09:00 and 17:00 with weekends and holidays subtracted. Configurable work window, working-day toggles (Mon–Fri default, change for Sun-start cultures or 6-day weeks), and a free-form holiday list. The breakdown lists each working day touched and how many hours were consumed there.

The breakdown is worth reading rather than skipping to the answer, because it shows where the hours actually went. A start time outside the work window is pushed to the opening of the next working period before any hours are counted, so a ticket raised at 18:00 on Friday consumes its first hour on Monday morning and the elapsed calendar time bears no relation to the working hours spent. That gap is precisely what an SLA is meant to express and precisely what people are surprised by.

The work window is treated as continuous. A lunch break is not modelled, so a 09:00 to 17:00 day counts as eight hours rather than seven, and a team that stops for an hour should configure the window to match, or accept that every multi-day estimate drifts by an hour per day.

Everything runs in your device's time zone. An SLA agreed with a customer in another country is measured against their working day, not yours, and a calculation done here from a different zone lands on the wrong hours entirely. Daylight saving is the same trap in miniature: the day a clock shifts has 23 or 25 hours in it, but the working window is defined by wall-clock times and still counts eight.

Holidays are pasted rather than looked up, for the same reason they always are: national holidays differ, some follow a lunar calendar, and a company's own closures are not published anywhere.

Frequently asked questions

What if the start is outside the work window?

It rolls forward to the next working day's start. Adding 1 h to Saturday at 03:00 with a Mon–Fri 9–17 window lands at Monday 10:00.

Does it handle partial hours?

Yes — the hours field accepts decimals (e.g. 2.5). Day-end overflow rolls cleanly to the next working day with the remaining fraction.

Which time zone does the work window apply in?

The same one the start time is read in, so nine-to-five means the local nine-to-five. When a clock crosses zones — a customer in one, the team in another — decide first whose working day the commitment is measured in, because the same number of hours lands on a different timestamp depending on the answer.

What happens if the daylight-saving change falls inside the span?

A working day here is defined by clock times, not by elapsed hours, so a day that shifts still runs 09:00 to 17:00 on the clock even though it lasts 23 or 25 real hours. That is normally what an office-hours commitment means. If yours is written in elapsed time instead, calculate it as a duration rather than as business hours.

Related tools