Why daylight saving and leap years should not confuse a workday count
A business-day question normally concerns named calendar dates: Monday, Tuesday and so on. It does not ask how many blocks of exactly twenty-four hours elapsed between two local midnights. That distinction prevents daylight-saving changes from producing unexpected fractions or an incorrect date count.
Count the dates, not the clock hours
Consider Friday, March 6 through Monday, March 9, 2026 in a US location that observes daylight saving. With a Monday–Friday schedule, no holiday exclusions and the start excluded, Monday is the only counted working date. The answer is one business day.
During that weekend, the local clock advances. The elapsed time between the two local midnights is not three ordinary twenty-four-hour blocks. Dividing that duration by twenty-four and rounding is therefore an unreliable way to discover which calendar dates occurred. The U.S. Naval Observatory explains the current US clock-change rule.
The opposite transition creates a longer clock interval in autumn. Neither change adds or removes a Monday from the civil calendar. A date-only tool should give the same count when opened in different browser time zones, provided the user entered the same dates and schedule.
Leap day is a real calendar date
Leap years require a different kind of care. February 29 actually exists in a leap year and must be considered like any other date. In 2028, February 28 is Monday, February 29 is Tuesday and March 1 is Wednesday. Counting after February 28 through March 1 on a Monday–Friday schedule gives two business days: Tuesday and Wednesday.
The Gregorian rule is divisible by four, except a century year must also be divisible by four hundred. Thus 2000 was a leap year and 2100 will not be one. The Naval Observatory's leap-year explanation provides the underlying calendar rule.
An invalid entry such as February 29, 2027 should produce a clear validation message. It should not silently turn into March 1. Silent normalization makes a result look trustworthy even though it answered a different question.
How the calculation stays consistent
A robust implementation first validates the year, month and day. It then works with whole civil dates or a consistently UTC-based day index. If JavaScript's Date.UTC is used, its resulting components must be checked against the entered values, because the function normalizes out-of-range components. Its special treatment of years zero through ninety-nine must also be avoided or handled explicitly. These behaviors are documented in MDN's Date.UTC reference.
Those are implementation checks; the user should not have to convert a date to UTC. Enter the date written on the schedule and read the eligible dates shown in the result.
If the real task is elapsed working hours, an appointment across time zones or a cutoff at a particular local time, a date-only answer is incomplete. Use the actual time zone, working hours and organization rules for that task. For ordinary date counting, the calendar-day approach keeps clock changes from becoming accidental extra or missing business days.
Put the example to work
Open the business days calculator and replace the example values with your own measurements. Keep the assumptions and result together using Download CSV or Print.
Sources & further reading
Source material checked November 9, 2026. This guide is an original explanation; source publishers do not endorse this website.