Product Decisions This Supports
- Feature scope: Enables calendar-aware business-day behavior in Laravel/PHP products without custom date math: add/subtract working days, skip weekends, account for configured holidays, and calculate due dates, SLAs, billing dates, trial expirations, approval deadlines, and delivery estimates.
- Roadmap prioritization: Unblocks or de-risks customer-facing commitments such as “3 business days,” “next working day,” “due before close of business,” and “SLA excludes holidays.” Product can commit to these semantics earlier because implementation is not a bespoke research project.
- Build vs. buy: Favor adopt OSS over building a date engine from scratch. The package is MIT-licensed and fits the existing Carbon/Laravel ecosystem, so the trade is a small dependency and integration effort against avoided edge-case maintenance. Keep it behind an internal service/interface so it can be replaced.
- Use cases: Support/helpdesk SLA timers, invoice and payment due dates, subscription renewal/dunning windows, procurement approvals, HR leave workflows, logistics ETA ranges, project task scheduling, compliance deadlines, and customer-facing “business days” messaging.
- Product risk reduction: Centralizes business-day semantics so different features do not ship inconsistent interpretations of weekends, holidays, and due dates.
- Decision guardrail: Treat it as a date-arithmetic utility, not a full scheduling/calendar platform. Product should avoid promising complex recurrence, resource availability, or multi-calendar scheduling on this package alone.
When to Consider This Package
Consider adoption when:
- The product already uses Carbon (directly or through Laravel) and needs business-day arithmetic with configurable holidays.
- Requirements are mostly “N business days from a date” or “is this a business day?”, not full calendaring.
- Date logic affects customer promises, SLAs, billing, or compliance workflows where inconsistent manual Carbon calculations are a real risk.
- The team can pin the dependency, wrap it behind an internal API, and add tests for holiday calendars, time zones, and boundary cases.
- A low-to-medium criticality feature needs faster delivery; a pilot can validate behavior before broader rollout.
Look elsewhere or build a more controlled solution when:
- The product needs full calendar scheduling: recurring events (RRULE), working hours, resource capacity, appointment booking, or complex multi-calendar availability.
- Holiday data must be sourced, curated, and updated across many jurisdictions; this package may calculate using holidays you supply, but it is not a holiday-data service.
- The domain requires enterprise support, auditability, or strict compliance guarantees beyond a small OSS dependency.
- The team cannot tolerate dependency risk: note the package has moderate stars but 0 dependents, so ecosystem validation is thin. Run a spike and review maintenance, test coverage, and issue responsiveness before making it foundational.
- Date behavior must be exact across DST/time-zone edge cases beyond standard Carbon handling; validate carefully or use a dedicated scheduling/time-zone service.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed Laravel/PHP utility that lets us ship “business-day” promises faster and with less risk of inconsistent date logic. It avoids reinventing edge-case date math and supports revenue-adjacent workflows like SLAs, billing due dates, approvals, and delivery estimates. Recommendation: adopt for targeted features, wrap it internally, and avoid treating it as a full scheduling platform.
For engineering: cmixin/business-day is a Carbon mixin for business-day calculations. It fits Laravel’s existing date stack and should be isolated behind a domain service so the rest of the codebase does not couple directly to the package. Add tests for holidays, weekend boundaries, month/year rollovers, and time zones. Because dependents are low, pin the version and treat adoption as a controlled pilot rather than an untested standard.
Decision summary: Good candidate for targeted business-day arithmetic; not a substitute for a calendar/scheduling engine. Adopt behind an interface, validate with tests, and revisit if requirements expand into recurrence, capacity, or holiday-data management.