Nth weekday after a date

This nth weekday after a date calculator turns a precise recurrence rule into one unambiguous calendar date. Provide a real ISO date in YYYY-MM-DD form, choose an English weekday, and enter which future occurrence you want. The search is strictly after the supplied date, so a Monday base with Monday selected returns the following Monday for the first occurrence rather than returning the base itself. All work uses pure proleptic Gregorian integer arithmetic without JavaScript Date, the system clock, locale settings, network calls, or random values. That makes the result stable for UTC-oriented automation, tests, schedules, reports, and data pipelines.

Understand the strict-after recurrence rule

The most important part of this calculator is the word strictly. The supplied ISO date is a boundary and is never eligible to be returned. Imagine the base is 2024-03-18, which is a Monday, and the selected weekday is also Monday.

The first Monday strictly after that boundary is 2024-03-25, not 2024-03-18. The second is 2024-04-01, and each later occurrence advances by exactly seven civil days. When the base weekday differs from the target, the engine first moves forward by the smallest positive number of days that reaches the target.

From a Friday base, the first Monday is three days later; the second is ten days later; the third is seventeen days later. This definition is useful because it avoids an easy off-by-one ambiguity between “on or after” and “after.” The tool treats dates as civil Gregorian days rather than instants with hours, offsets, or daylight-saving transitions.

Consequently, it does not skip weekends or holidays, and it does not reinterpret the date according to a device timezone. If you need an inclusive next-weekday answer, a business-day calendar, or holiday-aware scheduling, use a capability designed for that different rule. Here, every valid request has one exact mathematical answer governed only by the three explicit inputs.

Provide valid date, weekday, and occurrence inputs

Send three required fields named date, weekday, and n. The date must be a string with exactly four year digits, two month digits, and two day digits separated by hyphens. It must also identify a real day in the proleptic Gregorian calendar: 2024-02-29 is valid because 2024 is a leap year, while 2023-02-29 is rejected.

Supported years run from 0001 through 9999, and the result must remain inside that range. The weekday accepts English full names Monday through Sunday and familiar abbreviations such as Mon, Tue, Wed, Thu, Fri, Sat, and Sun without regard to letter case. Numeric weekday indexes and localized weekday names are intentionally rejected so their interpretation cannot vary.

The n field is one-based: one asks for the first matching weekday after the boundary, two asks for the second, and so on. It must be a positive integer no greater than 100000; integer strings are accepted for ordinary form submissions, but fractions, zero, negative values, NaN, Infinity, and unrelated text fail validation. A successful response never silently clamps a value, changes an impossible date, or returns a partial object.

Use deterministic Gregorian arithmetic in automation

Internally, the solver first checks month lengths and Gregorian leap-year rules, including the century exception: years divisible by one hundred are not leap years unless they are also divisible by four hundred. It then converts the accepted civil date into an integer serial day using a closed-form Gregorian transformation. The weekday follows directly from that serial count, with a fixed mapping from Sunday through Saturday.

The offset to the target is calculated modulo seven, but a zero modular distance is replaced with seven to enforce strict-after behavior. Seven times n minus one is added for later occurrences, and the final serial value is converted back to year, month, and day. This route is constant-time even for a large n; it never loops through all intervening dates.

More importantly, it does not construct a JavaScript Date, read the host clock, contact a calendar service, sample randomness, or apply operating-system timezone data. Scheduling systems can materialize the fifth Friday after a cutoff, reporting pipelines can calculate future observation dates, and test suites can build stable recurrence cases without freezing a clock. The result is expressed as an ISO civil date and component integers, not as a timestamp, because the input contains no time or zone.

A downstream system that needs a UTC instant can deliberately attach its own time-of-day convention after receiving this date, avoiding hidden assumptions inside the recurrence calculation itself.