One Answer to "Is This a Working Day"
Leave arithmetic and workflow deadlines used to answer the same question differently — one read a hardcoded weekend, the other a hardcoded working week with no holidays at all. They now resolve through one calendar, and the interesting part is what happens when that calendar has no working days in it.
An organisation that works Sunday to Thursday told the system so, and its approval deadlines kept landing on Fridays.
Two parts of this product need to know whether a date is a working day. Leave arithmetic needs it to count how many days a request consumes. Workflow deadlines need it to work out when something is due and when to escalate. Those are the same question, and for a long time they had two different answers.
Two hardcoded assumptions, pointing different ways
| What it used to read | What that produced | |
|---|---|---|
| Leave arithmetic | A hardcoded Saturday and Sunday weekend | A leave request spanning a Friday counted a day the organisation did not work. |
| Workflow deadlines | A separate calendar record, falling back to a hardcoded Monday-to-Friday week with no holidays | Deadlines computed on a Western week, and approvals due on public holidays. |
The failure worth dwelling on is the second one. An organisation could go into the settings, configure its working week correctly, see leave arithmetic respect it, and still have every workflow deadline computed against a week it does not work — because that half of the product was reading somewhere else entirely, and falling back to an assumption when it found nothing.
Two answers to one question is always a defect waiting
It is rarely discovered as a bug, because each half is internally consistent and correct-looking. It surfaces as a disagreement between two screens, months later, usually reported as "the deadline is wrong" rather than as "these two features disagree about the weekend". The fix is never to correct one of them — it is to make there be one answer.
One calendar, two sources
The single answer is built from two things the organisation already maintains: its configured working week, and its own public holidays with recurring entries expanded for each year.
That second detail matters more than it sounds. A holiday that recurs annually is stored once and expanded per year rather than needing to be re-entered, which is the difference between a calendar that stays correct and one that is correct in the year somebody set it up.
A recurring holiday entered once is a calendar that survives its author.
The escape hatch, and the honest note beside it
Workflow deadlines still check for an explicitly defined calendar first, then a shared one, before falling back to the organisation's own. That exists for a genuine case — a support desk operating seven days against an organisation that does not.
What is unusually honest is the note recorded beside it: in practice the fallback is what every organisation uses, because no such records exist and there is no screen for creating one. The capability is in the resolution order and the way to use it is a conversation rather than a setting.
Documenting that plainly next to the code is worth more than most documentation. Without it, the next person reads a three-step resolution order and assumes the first two steps are in use somewhere — and builds around a configuration surface that does not exist.
The calendar with no working days
Here is the case that makes this article worth writing. Adding business days to a date means walking forward until enough working days have passed. If the calendar has no working days at all — every weekday marked non-working, or holidays covering the whole span — that walk never finishes.
It is not a hypothetical. A misconfigured working week, a holiday import that marked a range, an organisation part-way through setup: any of those produces a calendar that cannot answer the question, and the request computing a due date simply never returns.
-
The walk carries a budget
At most a year of calendar days for each business day sought. Generous enough that no legitimate calendar exhausts it, bounded enough that an impossible one terminates.
-
Exhausting it produces an answer, not an error
The plain calendar date is returned — the original date plus the number of days, ignoring working days entirely. Wrong, in a knowable direction, and available.
-
The reasoning is written down
A due date that is merely unhelpful beats a request that never returns. That sentence is the whole design philosophy of the guard, and it generalises to every loop that depends on data somebody can misconfigure.
The trade being made is worth being explicit about, because it goes the opposite way to most of the decisions in this product. Elsewhere the pattern is to refuse rather than to guess — an unmeasurable duration is left empty, a contradictory pair is rejected. Here a wrong answer is preferred, and the reason is that the alternative is not a refusal but a hang, which is a worse failure than any answer.
It works backwards too
The same routine handles a negative count, walking backwards through the same rule. That is what makes "three working days before the deadline" expressible — the reminder date for an approval, the escalation point, the notice period before an expiry. One implementation, both directions, one definition of a working day underneath.
Five questions to ask about business day arithmetic
Do leave and deadlines use the same calendar?
A good answer sounds like
Yes, one implementation.
What ours actually is
Yes, now. They previously had two independent answers, one hardcoded to a weekend and one to a working week with no holidays.
Where does the working week come from?
A good answer sounds like
A setting.
What ours actually is
The organisation's configured working week, and its own public holidays with recurring entries expanded per year.
Can one part of the product use a different calendar?
A good answer sounds like
Yes, with a caveat.
What ours actually is
The resolution order allows it for a purpose such as a seven-day support desk, and in practice every organisation uses the fallback — there is no screen for creating one.
What happens with a calendar that has no working days?
A good answer sounds like
It terminates.
What ours actually is
A bounded walk, and on exhaustion the plain calendar date — an unhelpful due date rather than a request that never returns.
Does it work backwards?
A good answer sounds like
Yes.
What ours actually is
Yes, through the same routine, which is what makes "three working days before" expressible for reminders and escalations.
What AWRA OpsHub does today
- One implementation answering whether a date is a working day, used by both leave arithmetic and workflow deadline calculation.
- The organisation's own configured working week as the source for which days count.
- The organisation's own public holidays, with recurring entries expanded per year so a holiday entered once stays correct.
- A resolution order allowing an explicitly defined calendar for a specific purpose, then a shared one, before the organisation's own.
- Business day arithmetic in both directions, so a deadline and a reminder before it are computed by the same routine.
- A bounded walk that terminates on a calendar with no working days, returning a plain calendar date rather than hanging.
- Results memoised for the duration of a request, since a calendar does not change mid-request and the arithmetic asks once per candidate day.
- A default working week applied where an explicit calendar declares none.
More we can add to your workspace
- A screen for defining a purpose-specific calendar, so the seven-day support desk case is configurable rather than a conversation.
- A warning when a calendar has no working days, at the moment it is configured rather than when a deadline lands strangely.
- Regional calendars within one organisation, for a business whose branches observe different holidays.
- Half-days, for organisations whose week includes one.
- A preview of a computed deadline against the calendar, so somebody can see why a date landed where it did.
- A shared holiday set per country, offered as a starting point rather than entered by hand.
Where we point you to a specialist
- We will keep one answer to whether a date is a working day. Two implementations of the same question are internally consistent, individually correct-looking, and produce a disagreement between two screens that gets reported months later as a wrong deadline rather than as a duplicated definition.
- We will return a bounded answer rather than hang on an impossible calendar. This runs against the usual preference for refusing over guessing, and the reason is that the alternative here is not a refusal but a request that never returns — which is a worse outcome than any answer.
- Which days your organisation works and which holidays it observes are yours to set. We will apply them consistently everywhere; publishing a default calendar for a country would be a guess about your business dressed as a convenience.
A warning when a configured calendar has no working days is the smallest piece here, and it moves the discovery from a strange deadline weeks later to the moment somebody saves the setting.
Calendars that fit an organisation
One definition serving both halves of the product is the hard part and it is done. What remains is configuration surface for the cases the fallback does not fit.
Purpose-specific calendars
A screen for the seven-day support desk case the resolution order already anticipates.
Calendars per region
Different holidays for branches in different places, within one organisation.
A configuration warning
A prompt when a calendar leaves no working days, at the moment it is saved rather than when a deadline lands oddly.
We publish scope, not dates.
Scope working calendarsCheck your working week is set
It governs leave arithmetic and every workflow deadline in the product, from one place. Confirming it once is worth more than correcting individual dates afterwards.
Talk through calendarsFrequently asked questions
Our working week is not Monday to Friday. Does the system handle that?
Yes, and it now handles it in both places rather than one. The configured working week and the organisation's own public holidays are the single source for whether a date counts, and both leave arithmetic and workflow deadlines resolve through it. Previously each read its own assumption, so an organisation could configure one correctly and still have deadlines computed on a week it does not work.
Do we have to enter a recurring holiday every year?
No. A recurring entry is stored once and expanded per year, which is the difference between a calendar that stays correct and one that was correct in the year somebody set it up. That is exactly the kind of maintenance nobody remembers to do, so it is worth confirming your holidays are entered as recurring where they should be.
Can our support desk use a seven-day calendar?
The resolution order allows for exactly that, and today it is a conversation rather than a setting — no such calendars exist and there is no screen for creating one, so in practice every organisation uses the fallback. That is documented plainly beside the code rather than left for somebody to discover, and building the configuration screen is a contained piece of work.
What happens if we misconfigure the calendar?
The arithmetic still terminates. A calendar with no working days at all — every weekday marked non-working, or holidays covering the span — would otherwise walk forever, so the search carries a budget and on exhaustion returns the plain calendar date. The result is an unhelpful due date rather than a request that never comes back, which is the right way round.
Why prefer a wrong answer here when the rest of the product refuses to guess?
Because the alternative in this case is not a refusal, it is a hang. Elsewhere — an unmeasured shift, a contradictory warehouse and location — refusing leaves somebody with a visible problem to fix. Here refusing would mean a page that never loads, which is a worse failure than any date, so the guard prefers termination and the reasoning is written down beside it.
Can we compute a date before a deadline as well as after?
Yes, through the same routine with a negative count, walking backwards under the same working day rule. That is what makes reminders and escalations expressible as "three working days before" rather than as a fixed number of calendar days that lands differently depending on which week it falls in.
