- Is mwsimple/scdatetimepicker-bundle a Laravel package?
- No. It is a Symfony bundle that integrates the SCDateTimePicker JavaScript widget, and it is written against the Symfony runtime contract: a Bundle subclass for kernel registration, a DependencyInjection extension for config loading, Twig form themes, and assets:install-style asset publication. Laravel has no kernel-bundle registry, no Twig renderer, and no Symfony DI extension pipeline, so nothing in the package targets Illuminate contracts.
- Can I composer require this bundle into a Laravel application?
- Composer may install the files, but Laravel will not auto-discover or resolve anything usable from it, and a service provider cannot wire it without duplicating the assumptions the bundle already makes about Symfony. The practical outcome is a dependency that sits unused while you rebuild its behaviour by hand. Treat the repository as a design reference rather than a package to install.
- Which parts of this bundle are actually reusable in a Laravel project?
- The real payload is thin: a form widget template plus a pinned Bootstrap DateTimePicker JS and CSS asset set. That payload is portable, the Symfony packaging around it is not. Read the Twig template as a reference for markup and attributes, then reimplement it as a Blade component and pull the underlying picker from npm through Vite.
- How do I build a Laravel datetime picker equivalent to this bundle?
- Create an anonymous Blade component such as x-datetime-picker with props for name, value, format, min, max, locale, and timezone. Install the picker as an npm dependency delivered through Vite, keep validation in a FormRequest, repopulate with old(), and format with Carbon. None of these steps need the bundle.
- Which JavaScript datetime picker does the bundle wrap, and is it still maintained?
- It integrates the SCDateTimePicker widget built on the Bootstrap DateTimePicker lineage from Eonasdan, which is end-of-life upstream in favour of Tempus Dominus. The exact pinned version is not confirmed in the available evaluation. Inheriting a deprecated client library for a new build is a poor trade, so verify the pinned version and its upstream activity before committing.
- Does the bundle provide server-side validation for date and time input?
- This is unverified: it is not established whether the bundle's form type validates input or leaves that entirely to the host application. In Laravel you should assume validation is your responsibility and put rules in a FormRequest, keeping server-side validation authoritative. The client-side picker is only a UX layer and cannot be trusted on its own.
- Why does my datetime picker field go blank after a Laravel validation error?
- Laravel's old() returns the raw submitted string, so if the picker's display format does not match what was submitted the field silently blanks on redisplay. Make the component accept the old value and render it in the expected display format, or normalise the format in a cast or mutator. This is the most common defect when hand-rolling picker components.
- How should I handle timezones with a client-side datetime picker in Laravel?
- Client-side pickers emit local time strings, while Laravel date validation and Carbon casting expect a defined input timezone. Decide up front whether the component emits local time or UTC ISO-8601 and enforce that decision in a cast or mutator before persisting. Mixing the two silently shifts stored timestamps.
- Is this bundle safe to depend on in production?
- The signals are weak: 11 stars, 0 dependents, and a single maintainer mean no ecosystem validation and no bus factor, and it is unverified whether any test coverage exists. A recent release on 2025-09-01 is the one positive signal, but a lone release cadence is not a durability guarantee. The larger risk sits in the supply chain, since the wrapped picker lineage is end-of-life upstream.
- What are the Laravel alternatives to this Symfony bundle?
- Use a Blade component with a maintained picker installed via npm and Vite, such as Tempus Dominus, Flatpickr, or even the native input type datetime-local, optionally wrapped in a Livewire component. Budget roughly 1 to 2 days for a single-form use case and 3 to 5 days for a reusable component with validation, old-input repopulation, locale, and timezone handling. A one-day spike is usually enough to confirm that adopting the bundle itself is the wrong path.