NETWORKDAYS.INTL

What it does

NETWORKDAYS.INTL(start_date, end_date, [weekend], [holidays])

NETWORKDAYS.INTL counts the whole working days in the interval from start_date to end_date, excluding days designated as weekend and any dates listed in holidays. It differs from NETWORKDAYS in exactly one respect: the weekend is an argument, not a constant, and it can name any subset of the week.

That single change is what makes the function usable outside the Saturday/Sunday world — Friday– Saturday weekends, single-day weekends, six-day working weeks, and (via the string form) arbitrary patterns such as "Wednesday and Sunday off".

The count itself is the same filtered enumeration: take the days of the interval, drop the ones whose weekday is designated weekend, drop the ones in holidays, return the remainder.

Arguments

NETWORKDAYS.INTL(start_date, end_date, [weekend], [holidays]) — two required and two optional.

start_date, end_date — the interval endpoints, as date serials.

weekend — optional. Two entirely different value shapes are accepted, and they are the reason this function needs a page.

As a number, the documented table is:

The two blocks have different generators, which is the trap. Codes 1–7 name consecutive pairs, and the pair for code n begins on the day n positions after Friday — code 1 is Saturday+Sunday, code 2 is Sunday+Monday, and so on around the week. Codes 11–17 name single days, running Sunday (11) through Saturday (17). There is no code for a non-consecutive pair; for that you need the string form. Note also that the single-day block starts at Sunday while the pair block starts at Saturday, so neither block's numbering aligns with the other's, nor with WEEKDAY's return_type numbering. Nothing about these tables is memorable, and guessing is unwise.

As a string, Microsoft documents: "Weekend string values are seven characters long and each character in the string represents a day of the week, starting with Monday." Each character is "1" for a non-workday or "0" for a workday, and "only the characters 1 and 0 are permitted in the string". So "0000011" is the ordinary Saturday/Sunday weekend, and "0100010" is Tuesday and Saturday off.

Three details about the string form:

• It starts with Monday, which is not the convention any of this function's numeric tables use and not the convention WEEKDAY's default return_type uses.
• "1111111" is invalid — the WORKDAY.INTL page states the rule explicitly ("at least one workday required"), and the same argument is shared by both functions. Whether NETWORKDAYS.INTL rejects it identically is a natural check that has not been run here; a zero-workday week would make the count trivially 0 rather than undefined, so the two functions could defensibly differ.
• It is text, not a number. A weekend of 0000011 written without quotes is the number 11, which is a valid numeric code meaning "Sunday only" — a silent, plausible-looking wrong answer rather than an error. This is the sharpest foot-gun in the function.

holidays — optional range or array of dates to exclude, as on NETWORKDAYS.

Try it

Quirks

Result and edge cases

Returns a Number: a count of working days.

• Inclusivity of the endpoints is not stated on the Microsoft page, exactly as with NETWORKDAYS. The expected behaviour is that both endpoints count, and NETWORKDAYS.INTL(2,5,TRUE) = 4 fits it (FN-NETWORKDAYS.INTL-001).
• Reversed intervals — likewise undocumented and unverified.
• A weekend covering six days leaves one working day per week and is legal.
• Holidays landing on weekend days should contribute nothing, since the operation is exclusion; undocumented.
• Blank cells in a holidays range raise the Empty-versus-Missing question from the value universe, and serial 0 is inside the representable range — so a blank interpreted as a number is a date. Undocumented and a real hazard.

Errors

As documented on the Microsoft page:

• #NUM! when start_date or end_date is out of the valid date range.
• #VALUE! when "a weekend string is of invalid length or contains invalid characters".

Compare NETWORKDAYS, whose page documents #VALUE! "if any argument is not a valid date" — a different error value for what looks like the same failure. The Handbook records the discrepancy rather than resolving it by assumption; see claim language, rule 5.

The documented #VALUE! condition names only string invalidity. What an out-of-table numeric weekend code does is not stated on that page. Code 0 gives #NUM! (FN-NETWORKDAYS.INTL-001); 8, 10 and 18 are not asserted here.

How to implement

Notes for implementers

1. Normalize weekend to a seven-bit mask first, from either the numeric code or the string, and reject invalid inputs at that point. Every downstream step then sees one representation.
2. Get the Monday-first string convention right, and write a test that fails if the mask is reversed — a reversed mask is symmetric for the common "0000011"/"1100000" confusion only in the sense that both look plausible.
3. Use whole-week arithmetic, not enumeration. With a mask, the count over n whole weeks is n × popcount(¬mask), and only the partial week at each end needs a loop of at most six iterations. Enumeration over a century-scale interval is reachable and slow.
4. Decide the all-weekend ("1111111") policy deliberately and keep it consistent with WORKDAY.INTL, where the documentation is explicit that the string is invalid.
5. Do not accept a numeric weekend that happens to look like a mask. 11 is a table code, not a two-day pattern.

Rust code

22 networkdays_intl_fn "NETWORKDAYS.INTL" (2, 4) [V "start_date", V "end_date", V "weekend", R "holidays"] |s, a, sv| {
    networkdays(s, a, sv, true)
}

No implementation has been published with a Handbook test suite for this function.

Version differences

The recorded environments below distinguish a reading from a same-input comparison. Counts describe captured inputs in each environment; overlapping captures and comparisons are not totals of unique worksheet calls.

The record contains no same-input comparison between these environments. Reading different inputs on different builds does not establish either a version change or cross-build agreement.

Recorded environments and comparison details.

Alternatives

Relationships

• NETWORKDAYS — the un-generalized original. NETWORKDAYS(a,b,h) should equal NETWORKDAYS.INTL(a,b,1,h); that equivalence is unverified here and is the family's cleanest cross-check.
• WORKDAY.INTL — the inverse operation with the identical weekend argument. The two should agree about which days are weekends by construction, but their errors do not match: the documented tables are worded differently, and FN-NETWORKDAYS.INTL-001 measures different answers for errors in the date and weekend cells.
• WORKDAY — the un-generalized inverse.
• WEEKDAY — the underlying day-of-week notion, with yet another numbering convention. This family contains four mutually non-aligned weekday numberings: WEEKDAY's legacy codes, WEEKDAY's 11–17 block, .INTL's 1–7 pairs, and .INTL's Monday-first string. That is a genuine design fact about the surface and the source of most .INTL bugs.

Named variants

No named variants are recorded yet.