Intl Date Time Laravel Package

Product Decisions This Supports

• Feature scoping for internal admin tooling — not customer-facing surfaces. This is a Laravel Nova form field. The only question it answers is "how do we get locale-correct date entry into our Nova admin screens?" It has no leverage on the public API, customer web app, SDK, or data model. Any request citing it as a "localization initiative" or "platform investment" should be reframed — it isn't either.
• Build vs. fork vs. buy — and the honest answer is "fork or build." The package collapses a narrow but real chunk of work (locale-aware picker, Nova field wiring, validation, locale-aware formatting) into a single composer require. But the upstream repo is archived — 57 stars, zero dependents, single maintainer. That's not a vendor relationship; it's a source-code handoff. Frame the decision as "fork this MIT source and own it" vs. "build a thin owned field" (~150–300 lines of Flatpickr + Intl.DateTimeFormat), with roughly comparable engineering effort and the fork carrying permanent lifecycle cost.
• Localization roadmap sequencing. Regional date entry — DD/MM vs. MM/DD ordering, localized month and weekday names, 12h vs. 24h conventions — is a concrete, demoable slice of "we support market X." Shipping it into internal tooling is a cheap way to demonstrate locale-readiness and pressure-test workflows before committing engineering time to customer-facing localization.
• Data-quality and support-ticket triage. Ambiguous date entry (a user typing 03/04 meaning April 3rd) produces silent data errors that surface weeks later as reconciliation work, rework, or customer-facing mistakes. A locale-aware picker is a low-cost mitigation for distributed ops teams, and gives a defensible answer when someone asks "is bad date UX actually costing us money?"
• Admin-panel standardization. If several internal tools run on Nova, choosing one canonical date field is a small platform-consistency decision best made once, centrally — it concentrates upgrade-testing cost in one place instead of scattering it across projects.
• An explicit scope boundary to set with stakeholders. It formats dates for display and entry. It does not make date logic correct. Timezones, ranges, recurrence, DST, and business-day rules remain our problem on every path.

When to Consider This Package

Consider it when:

• You have an existing Laravel Nova installation and internal-only admin screens where ambiguous date entry is a data-quality risk but not a revenue event. Conditional on holding a Nova license — without Nova it is simply irrelevant.
• Your editors are geographically mixed and need locale-aware entry and display — a genuine gap in Nova's core Date/DateTime fields.
• You're building prototyping or short-lived internal tooling where a fork-and-own posture is acceptable and lifecycle cost doesn't compound.
• You want a reference implementation. MIT-licensed, tiny surface area (one field class plus a Vue component). Reading the source may be faster and more informative than evaluating commercial alternatives — and it will sharpen your estimate for the owned build, even if you never ship it.
• You can gate adoption on a one-day spike against your exact Nova major: install, render a resource form, save, reload, confirm round-trip. Non-negotiable first task, not last.
• You can pin Nova, PHP, and Node/browser versions in CI and name an owner for the fork before the first commit.

Look elsewhere when:

• Maintenance matters at all. Archived means no security patches, no Nova-major tracking, no PHP/Laravel upgrade support. Treat it as a code sample, not a standing dependency.
• You're on a current Nova major. Date fields are tightly coupled to Nova's field API and asset pipeline (Vite/Vue 3 vs. older Mix/Vue 2); archived fields of this vintage are routinely and silently broken by Nova upgrades — the field degrades to a plain text input and nobody notices until bad data lands.
• You need scheduling semantics — timezones, recurrence, ranges, business-day rules, date+time with DST correctness. A picker is presentation only.
• You need active maintenance, commercial support, or a compliance-credible dependency inventory for a security review.
• 57 stars, 0 dependents, single maintainer is a weak ecosystem signal. There is no community to catch regressions; any bug you hit, you own.
• You're not on Nova — evaluate Filament, Livewire, or plain Blade plus a maintained JS date library instead.

Decision rule for the PRD: default to not adopting. Adopt as a forked accelerator only if the Nova-version spike passes and an internal owner is named before the first commit.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) UI component that makes date entry behave correctly for international users inside our Laravel Nova admin. No license cost, and it is not a platform investment. It is, however, archived and unmaintained — so I do not recommend it as a standing dependency. If we use it, we vendor the source, own it, and expect to maintain it ourselves. The realistic alternative is a few days of internal work to build the same field in-house. Decision framing: adopt strictly as a short-term, internal-only accelerator behind an internal fork, gated on a compatibility spike — never as infrastructure, never on a customer-facing surface.

To engineering: Small, focused Nova field wrapping a locale-aware datepicker — one field class plus a Vue component, MIT licensed, so forking is unencumbered. Two hard caveats: it's archived (no upstream fixes, no Nova-major tracking) and it has effectively zero adoption, so there's no community safety net. Recommendation: treat it first as a reference implementation to scope our own build. If we adopt, fork it into an internal namespace via a VCS repository entry, pin it, rebuild assets under our toolchain, and add it to the maintained-dependency watchlist. Make "does it render and round-trip on our Nova version" the first task. Confirm it persists ISO-8601/UTC rather than localized display strings, verify server-side date/date_format validation instead of trusting the client's formatted value, and document locale and storage-format conventions so the field doesn't become tribal knowledge. If the spike fails on our Nova major, stop and build the thin owned field — comparable effort, materially less lifecycle risk.

One-line version for the roadmap review: A free, archived Nova date field that buys us a few days of engineering at the cost of permanent ownership — worth using only as a scoped reference or a forked internal accelerator, behind a passing compatibility spike.