| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Checkpoint | Timestamp | Offset | Business hours | Complete | Copy |
|---|---|---|---|---|---|
| {{ milestone.label }} | {{ milestone.timestamp }} | {{ milestone.offset }} | {{ milestone.businessHours }} | {{ milestone.completion }} |
Time differences become harder to reason about once time zones, work calendars, and milestone planning enter the picture. A simple count of hours is often not enough when one timestamp is in UTC, another is in local time, and the real question is how many working days fall between them. This calculator turns two moments into a structured interval report instead of a single raw subtraction.
The package accepts a start and end date-time, lets each one be interpreted as local time, UTC, or a fixed offset, then reports total years, months, weeks, days, hours, minutes, seconds, milliseconds, an ISO-style duration string, working-day counts, estimated working hours, offset shift, midpoint, and milestone checkpoints.
That makes it useful for several practical cases. A project manager can compare kickoff and deadline while excluding holidays and weekends. A distributed team can compare two regional timestamps without double-counting offset changes. A planner can use the midpoint and quarter checkpoints for review meetings or rollout phases rather than calculating them manually.
The package also separates calendar time from working time. Working-day totals depend on the selected working week, whether the end date is counted, business hours per day, and any holiday exclusions you entered. That distinction matters because a 10-day calendar gap can represent only 6 or 7 working days depending on the calendar rules.
The boundary is that this is a planning and comparison tool, not a legal timekeeping system. It relies on the timezone interpretation and holiday list you provide, so critical payroll, contractual, or audit decisions still need to be checked against your official systems of record.
Choose the timezone interpretation carefully before you read any totals. Local mode means the browser interprets the clock time using the device’s civil time. UTC mode pins the input to Coordinated Universal Time. Fixed-offset mode is for timestamps that came from a specific UTC offset and should not inherit the device’s local daylight-saving behavior.
The top summary is best read in layers. First use the human-readable duration and total-day/hour badges to understand the gross span. Then look at working-day totals, offset shift, and midpoint if the interval is being used for planning or scheduling rather than for simple elapsed time.
Holiday exclusions and the end-date toggle materially change working-day output. If the end date should count when it lands on a working day, turn that option on. If you are measuring “days remaining until” rather than “days fully completed before,” the distinction can matter more than the raw time difference itself.
The milestone table is most useful when the interval is being managed rather than merely measured. Quarter and midpoint timestamps are better planning anchors than ad hoc mental math, especially when the start and end are in different offsets or when business-hour conversion is part of the task.
Use the result comparatively. If a small timezone change or holiday list changes the working-day total more than expected, that is a sign the schedule is sensitive and deserves a closer check before it is treated as settled.
The core quantity is the signed difference between two interpreted instants, measured in milliseconds. The package then reports both an absolute elapsed duration and a chronology label telling you whether the end comes after or before the start. Absolute totals make the tables easier to compare, while the chronology label preserves direction.
The calendar breakdown is not just a simple division by fixed constants. The script walks from the earlier instant to the later one in years, then months, then days, then smaller units so month lengths and leap-year behavior are respected. Total decimal days, hours, minutes, and seconds are also calculated directly from the underlying date engine and then formatted using the chosen decimal precision.
Working-day counts are calculated separately from elapsed-time totals. The package iterates from the earlier day boundary to the later one, classifies each day according to the selected working-week model, subtracts any listed holidays, and optionally includes the ending day if that switch is enabled. Estimated working hours then multiply the working-day count by the configured business-hours-per-day value.
Midpoint and checkpoint milestones come from ratios of the absolute duration. The package computes start, 25 percent, 50 percent, 75 percent, and end markers by adding fixed fractions of the millisecond span to the earliest timestamp. Those rows feed both the milestone table and the checkpoint cadence chart.
| Input or option | Package behavior | Why it matters |
|---|---|---|
| Timezone mode | Each endpoint can be local, UTC, or a fixed UTC offset | Prevents silent reinterpretation of timestamps captured in different contexts |
| Working week | Defines which weekdays count as working days | Changes business-time totals without changing elapsed time |
| Holiday exclusions | Removes listed dates from working-day totals | Supports business calendars that differ from a plain weekday rule |
| Include end date | Optionally counts the ending calendar day in the working-day calculation | Helps match different operational counting rules |
| Business hours/day | Multiplies working days into estimated working hours | Provides a planning-oriented workload view |
| Surface | What it shows | Exports available |
|---|---|---|
| Summary table | Calendar totals, working-day counts, midpoint, and recommendation | CSV, DOCX, row copy |
| Milestones | Quarter checkpoints and midpoint timestamps | CSV and row copy |
| Charts | Working split, duration-unit view, and checkpoint cadence | Image and CSV exports |
| JSON | Inputs, totals, working-day settings, milestones, and recommendation | Clipboard copy and JSON download |
The total duration tells you how far apart the moments are; the working-day totals tell you how much operational time lives inside that span. Those are not the same thing, and the package keeps them separate so a schedule does not quietly inherit the wrong interpretation.
The offset-shift badge deserves attention whenever the two endpoints do not share the same timezone interpretation. A large shift can explain why a manually estimated gap felt wrong even when the timestamps looked close on paper.
A team compares kickoff and delivery dates and sees a 14-day calendar gap. After applying a Monday-to-Friday workweek and two holiday exclusions, the business-time total drops meaningfully, which better reflects the real working window.
One system logs an event in UTC while another team enters a deadline in a fixed local offset. Setting both endpoints explicitly prevents double-counting timezone shifts and makes the midpoint and milestones more reliable for planning.
Because the package excludes non-working weekdays and any holiday dates you supplied from the business-time calculation.
The midpoint is displayed relative to the earliest interpreted instant, which keeps the milestone view consistent across the interval.
No. It is a planning and comparison tool, not an authoritative compliance or timekeeping ledger.
P3DT4H used to express elapsed time.