Weave Code
Opening Hours For Laravel Laravel Package
roundly-consulting/opening-hours-for-laravel
Opening Hours for Laravel lets you define weekly business hours and query open/closed status directly from your app. It supports timezones, exceptions, holidays, and multiple schedules, making it easy to show availability or enforce opening-hour rules in Laravel projects.
Opening hours, seasonal schedules, exceptions and bookable availability for any Eloquent model — DST-correct, native, zero third-party deps.
Frequently asked questions about Opening Hours For Laravel
- How do I install opening-hours-for-laravel in a Laravel app?
- Require it with Composer using roundly-consulting/opening-hours-for-laravel, then publish the package config with the standard vendor:publish command if you want to customize the defaults. There is no build step, runtime service, or infrastructure change, because it is a library-level dependency that plugs into Laravel through the usual service provider and facade idiom. For reproducible upgrades, pin to ^1.1 and resolve the whole Roundly family in a single Composer pass.
- How do I define weekly opening hours with multiple time slots per day?
- You configure a weekly schedule in which each day of the week can hold one or more time ranges, so split shifts such as a lunch break are simply two slots on the same day. The schedule lives in the package configuration and the fluent API evaluates it at query time. Because evaluation is timezone-aware, you do not need to pre-normalize times before defining them.
- How can I check whether a business is open or closed at a given moment?
- Use the package's fluent API, typically through its facade, to ask for open or closed status at a moment in time, and the weekly schedule plus any date-specific exceptions are evaluated for you. The same call works for right now or for an arbitrary datetime you pass in. That makes it suitable both for rendering an open-now badge and for enforcing opening-hour rules inside business logic.
- Does it handle timezones for opening hours?
- Yes. Schedule evaluation is timezone-aware, so hours can be defined and checked against the timezone that applies to the business rather than the server default. This matters for apps serving multiple regions or running on UTC infrastructure, where midnight boundaries do not line up. Check how your config maps schedule timezones to your application's own timezone setting.
- How do I handle holidays and one-off exception dates?
- The package supports date-specific exceptions alongside the recurring weekly schedule, so you can mark holidays, temporary closures, or special hours for a single date without rewriting the weekly pattern. Exceptions are part of the configuration, which means they can be version-controlled with your app or generated dynamically depending on your setup. Test an exception against a normal weekday to confirm how precedence between exceptions and regular hours is resolved.
- Which Laravel and PHP versions does this package support?
- Version 1.1.1 inherits its framework constraints from the Roundly package-toolkit, and that release raised the minimums to package-toolkit ^1.3.0, enums ^1.1.0, and the dev testing package ^1.2.1. The practical answer is that the supported PHP and Laravel range is whatever that toolkit floor declares, so read composer.json instead of assuming. If you need a published version matrix, treat the declared Composer constraints as the source of truth.
- Can I define more than one schedule, for example for multiple locations?
- Yes, multiple schedules are supported, so separate branches, locations, or service types can each carry their own weekly hours and exceptions. Each schedule is evaluated independently through the fluent API, which keeps per-location availability logic out of your controllers. It is also a clean way to model different hour sets such as support hours versus sales hours in the same application.
- What changed in version 1.1.1 and is it a breaking change?
- 1.1.1 is a constraint-only release: no public API, signature, or config changes, and no deprecations or removals. It raises minimum dependency versions to package-toolkit ^1.3.0, enums ^1.1.0, and dev testing ^1.2.1. The patch version number matches that scope, but the toolkit and enums minor bumps are transitive and outside this package's own changelog, so review them before adopting.
- Will upgrading this package force upgrades of other Roundly packages?
- Probably yes. Because the constraints are caret ranges, installing 1.1.1 pulls package-toolkit 1.3.x and enums 1.1.x, and any sibling Roundly package still pinned to toolkit ^1.2 or enums ^1.0 will block resolution. The fix is a coordinated family upgrade rather than holding the toolkit back. Before merging, run composer why on the toolkit package to inventory your app's current pins.
- Is it safe to use in production, and how is the package maintained?
- It is a low-risk, library-level dependency with no runtime service or infrastructure delta, so the real operational cost is tracking the sibling Roundly packages that ship in coordinated patch releases. The 1.x line is the active one, and releases are signalled through the changelog and tagged diffs, which you should treat as the source of truth for any support window. In CI, run a prefer-lowest pass so the declared minimum versions are actually exercised. Pin exact versions only temporarily during rollout, then relax back to caret ranges.
Weaver
How can I help you explore Laravel packages today?