- Can I install mablae/time-window-bundle in a Laravel app?
- No. mablae/time-window-bundle is a Symfony bundle, and Laravel does not load Symfony bundles: there is no kernel, bundle registration, or DI extension. Composer may install it, but the services and configuration tree will never boot, so the time window checks are unreachable from a Laravel application.
- What does mablae/time-window-bundle actually do?
- It lets you register named time windows in Symfony configuration and services, then test any DateTimeInterface against them. Windows can be recurring, such as business hours or weekly maintenance slots, or one-off promotional ranges. The goal is to keep scheduling logic out of controllers and templates.
- Does it support recurring daily, weekly, and seasonal time windows?
- Yes, the bundle is designed for recurring schedules including daily, weekly, and seasonal windows, plus absolute one-off ranges. Each window is declared in configuration and exposed as a service. You evaluate a DateTimeInterface against the window to get a boolean result.
- Is this bundle timezone-aware, and how does it handle DST?
- Timezone-aware comparison is part of the bundle's stated feature set, so windows can be evaluated consistently across regions. However, with zero adoption there is no public evidence of how app timezone, UTC, and per-window timezones are resolved. You should verify DST transition behavior and inclusive versus exclusive boundaries before relying on it.
- How do I check whether the current time is inside a time window?
- In Symfony you register a window as a service and call its boolean check with the current DateTimeInterface. In Laravel there is no supported path because the bundle never boots. The practical equivalent is a small TimeWindow value object and a FeatureFlagService singleton in your own package.
- Is mablae/time-window-bundle production-ready and actively maintained?
- Treat it as a personal bundle rather than a production dependency. It has zero stars, zero dependents, no visible release cadence, and a bus factor of one. That means no issue history or downstream projects to infer API stability from, which is a high maturity risk for anything on a hot path.
- What is the best Laravel alternative for time-based feature flags?
- The recommended Laravel alternative is to port the pattern, not the code. Declare windows per flag in config/feature-flags.php, add a TimeWindow value object with explicit timezone handling, bind a FeatureFlagService as a singleton, and expose a Blade directive or a Feature::active facade. If you need broader flag capability later, layer Laravel Pennant on top and supply a time-window scope.
- Does it integrate with Laravel Pennant, facades, or Blade directives?
- No. Laravel Pennant and Blade directives have no bridge to Symfony bundle conventions, and the bundle ships no Laravel service provider or facade. You would have to write that integration yourself, at which point you are reimplementing the evaluator anyway.
- How long does it take to reimplement time windows in Laravel?
- It is a bounded effort, roughly one to two days, not a migration. The core logic is a thin predicate: given a flag name and a config-declared window, compare now() against the boundaries. The work is mostly in getting timezone resolution, DST edges, and boundary inclusivity right, plus wiring config and a singleton service.
- Should I add this as a Composer dependency for scheduling rules?
- No, adding this dependency is a bad trade. You would take on a transitive Symfony dependency and a supply-chain surface to obtain roughly fifty lines of date comparison, with no production usage trail to justify it. Read the bundle's DependencyInjection and evaluator classes as reference, then implement the pattern natively in Laravel.