Nova Opening Hours Laravel Package

Product Decisions This Supports

• Feature delivery: Enables scheduling, booking, reservation, availability, and resource-allocation features that depend on detecting overlapping date/time (or numeric) ranges without bespoke validation code.
• Build vs buy: Argues for adopting a small, focused validation package rather than building and maintaining custom overlap logic in-house — overlap checks have subtle edge cases (inclusive/exclusive boundaries, open-ended ranges, time zones, multi-resource conflicts) that are easy to get wrong.
• Roadmap sequencing: Lowers the cost of shipping adjacent features such as appointment booking, shift planning, campaign/promo date windows, subscription periods, and room/equipment reservations. The new overlap rule in 0.3.0 directly expands the set of validation-heavy features the team can ship without custom engineering.
• Risk reduction: Centralizing overlap validation reduces the chance of double-booking and conflicting-date bugs reaching production, which are high-visibility, high-cost defects in customer-facing scheduling flows.
• Use cases to prioritize: Date-range conflict checks on create/update forms, API payload validation for booking endpoints, admin-side scheduling tools, and capacity/availability pre-checks. Less suited to full recurrence logic or complex capacity constraints, which likely still need domain modeling.

When to Consider This Package

Adopt when:

• The product is a Laravel/PHP application with validation needs around date ranges, time windows, or numeric ranges.
• Multiple features or teams need consistent, reusable overlap validation rather than one-off checks.
• Engineering values declarative Laravel validation rules and wants predictable error messaging.
• The overlap requirement is moderate: pairwise range conflicts, form/API validation, booking conflict prevention.
• The team can tolerate a pre-1.0 dependency (0.3.0) by pinning versions and reviewing changelogs.

Look elsewhere when:

• The stack is not Laravel/PHP.
• Overlap logic is core domain complexity — recurrence rules, multi-resource capacity, buffered appointments, or database-enforced exclusion constraints — where a validation rule alone is insufficient.
• The team requires a stable 1.0+ API contract or long-term support guarantees.
• Only a single trivial overlap check is needed, making an in-house one-liner cheaper than a dependency.
• Database-level constraints (e.g., exclusion constraints, unique indexes) are the preferred source of truth for conflict prevention.

How to Pitch It (Stakeholders)

For executives: This package gives our Laravel application a ready-made way to validate overlapping dates and ranges — the kind of check behind booking conflicts, scheduling clashes, and availability windows. The 0.3.0 release adds an overlap validation rule, which means we can ship scheduling-related features faster and with fewer double-booking defects, without building and maintaining custom validation logic. It is a small, focused dependency; the main caveat is that it is pre-1.0, so we should pin the version and review future releases before upgrading.

For engineering: A Laravel validation package that now includes an overlap rule, usable alongside existing validation rules for date/time and numeric ranges. It reduces bespoke conflict-detection code and standardizes error handling. Adopt it for form/API validation where pairwise overlap checks are sufficient; keep domain-heavy conflict logic (recurrence, capacity, database-enforced constraints) in application or database layers. Because 0.3.0 is pre-1.0, pin the version, add coverage around boundary conditions, and treat minor releases as potentially containing behavior changes.