Laravel Workdays Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling/availability logic: Use the package as the scheduling engine instead of building working-time, DST, SLA, and calendar arithmetic in-house, especially for Laravel products that need configurable business hours and service-level calculations.
• Roadmap acceleration for SLA and availability features: The unified working-time calculations, microsecond precision, revised DST handling, reverse scheduling, and snapshot validation reduce the engineering lift for SLA dashboards, breach prediction, and “next available slot” experiences.
• Localization strategy for Iran/MENA markets: Restored Iran calendar imports, Persian documentation, and RTL rendering fixes make this a credible enabler for Persian-language scheduling workflows and Iran-specific calendar requirements.
• Configuration and operations architecture: The move to a single configuration source and operation context supports cleaner admin tooling, environment-specific behavior, and fewer configuration mismatches across services.
• Storage and auditability decisions: Revision-based database storage plus atomic publication supports versioned scheduling definitions, safe rollout of configuration changes, and audit-friendly operations—useful for enterprise or regulated customers.
• Import/export and migration workflows: Configuration import/export and restore capabilities support onboarding, environment promotion, backup/recovery, and tenant-level configuration management.

When to Consider This Package

• Adopt when: You are building a Laravel/PHP application that needs calendar-aware scheduling, business-hours calculations, SLA computation, availability rules, or Persian/Iran calendar support, and you want tested primitives rather than bespoke date logic.
• Adopt when: You need either configuration-file-driven definitions or database-backed definitions with revision history and atomic publication, and you value a unified configuration model.
• Adopt when: Persian-language UI and RTL documentation are requirements, or when Iran calendar handling is part of the product scope.
• Adopt with migration caution when: You are already using legacy configuration structures or the removed Chain/Hybrid storage modes. v1.0.0 introduces breaking changes, so plan a migration and regression-test working-time boundary behavior, DST cases, SLA calculations, and stored definitions.
• Look elsewhere when: You need a full calendar UI, drag-and-drop scheduling front end, distributed job scheduling at very high scale, non-Laravel/non-PHP interoperability, or broad multi-calendar support beyond the package’s scope.
• Look elsewhere when: Your team cannot absorb the breaking-change migration or does not need Persian calendar, SLA, or working-time features; simpler date libraries may be sufficient.

How to Pitch It (Stakeholders)

• For executives: This release matures the package into a v1.0.0 scheduling foundation with unified configuration, versioned database storage, atomic publication, and stronger SLA/DST handling. It can reduce time-to-market for scheduling and service-level features, especially for Iran/MENA localization, while lowering the risk of custom date-math defects. The trade-off is a breaking-change migration for existing adopters.
• For engineering: v1.0.0 simplifies configuration into one source and operation context, adds revision-based storage with atomic publication, improves working-time precision and DST/boundary behavior, restores Iran calendar imports, and adds regression/database/integration tests. It removes legacy configuration structures and Chain/Hybrid storage modes, so migration work is required. Adopt for new scheduling/SLA work; migrate existing integrations deliberately and validate boundary, DST, and snapshot behavior.