Datetimepicker Bundle Laravel Package

Product Decisions This Supports

• Form UX for scheduling surfaces — booking flows, appointment/resource scheduling, report date-range filters, admin back-office forms. Anywhere users pick a date, a time, or both, this package is a candidate for the input control.
• Build vs. buy diligence — this is the "buy" option that fails the screen. It's most useful as a worked example of the criteria we should apply before a spike, not after.
• Stack standardization — the package is a Symfony bundle, not a Laravel package. Its presence in a Laravel evaluation set is itself a signal: we need a per-framework decision on form widgets rather than one "PHP date picker" decision.
• Dependency policy — 0 stars, 0 dependents, no release since 2015-02-11. Concrete evidence for setting a maintenance bar (recent release, active dependents, supported framework versions) as a gate on third-party UI dependencies.
• Technical-debt and upgrade planning — adopting an unmaintained form-layer dependency tends to pin the framework version. This informs how we scope framework upgrades.
• Roadmap prioritization — the opportunity score (6.59) points at real, recurring unmet demand for good date/time input UX. That argues for a small internal component budget, not for this package.

When to Consider This Package

Narrow cases where it's even worth opening the repo:

• You maintain a legacy Symfony 2.x application on PHP 5.x/7.0-era runtimes, you need an in-form date picker, and you have no budget for anything else.
• You want a reference implementation — read the source to see how a JS picker gets wired into a Symfony form type. Read, don't require.
• A throwaway spike or internal demo that will never ship to production.

When to look elsewhere (in practice, always):

• Laravel stack. Wrong framework. Do not bridge a Symfony bundle into Laravel; the integration cost exceeds building the widget.
• Modern Symfony (5/6/7) or PHP 8+. No release in ~a decade; service definitions, form type signatures, and template assumptions will not line up.
• Any production, user-facing use. Zero community adoption means zero canary users, no security review, no bug reports, no one to ask.
• If accessibility, locale-specific date formats, timezone/DST correctness, or mobile input quality are requirements — all of which they typically are for scheduling.
• If you need a vendor relationship, SLA, or a CVE response path.

Evaluate instead: flatpickr, Tempus Dominus, or native <input type="datetime-local">, wrapped in a thin adapter you own. All actively maintained, framework-agnostic, MIT/BSD.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. This is not a close build-vs-buy call, and spending evaluation time on it further is not a good use of the team.

Why, in one line: an abandoned 2015 Symfony bundle with no adoption, no maintenance path, and the wrong framework for our stack.

Risks if we adopted it anyway:

• An unpatched component sitting directly in our user-facing form layer — security and accessibility exposure we'd own with no upstream fix.
• Framework upgrade blockage: pinning the app to an old Symfony/PHP combination.
• Unbudgeted maintenance: we'd effectively be forking and maintaining it, at which point we've paid the "buy" cost and the "build" cost.

What we do instead: a thin internal wrapper over a maintained JS picker (or native inputs where acceptable) — roughly 1–2 engineering days, owned by us, covered by our tests, upgradeable on our schedule.

What the data actually tells us: the opportunity signal (6.59) is the useful part of this assessment. Date/time entry is a persistent, cross-product UX pain point, and there's no obvious maintained PHP-framework package filling it. That justifies a small, reusable internal component on the roadmap — and it's a case where building is genuinely cheaper than buying.

Ask: approve the small internal component work, and ratify a dependency bar (a release within the last 12 months, active dependents, explicit support for our framework version) so future evaluations resolve in minutes rather than days. MIT licensing means we can still borrow patterns from this repo's source for free.