Intl Date Time Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova form field, not a general-purpose date library. Mechanically it is a Composer package whose service provider registers a compiled Vue component through Nova's asset pipeline, with ICU pattern formatting driving display. That makes the fit test binary and cheap to run: are we on Nova, and do any admin users actually enter dates in a non-US locale? If either answer is no — a non-Nova Laravel app, or an English/US-only admin — fit is zero, and there is no salvageable surface (no Blade component, no headless API, no framework-agnostic helper to lift out). Where it does fit, it closes a narrow but real gap: Nova's native Date/DateTime fields do not handle DD/MM vs. MM/DD ordering, localized month/weekday names, or 12h/24h conventions, so a mixed-locale ops team produces silent, misreadable input. The TPM framing is that this is a cheap mitigation for a measurable class of data-entry errors and downstream reconciliation work — not a localization platform investment, and not something that touches the public API, customer web app, or data model.

Integration feasibility. Low engineering effort, high decision clarity. There is no migration, no config publish, no queue, no data-model change — the field is declarative and stateless, so rollout is a single composer require plus one field declaration on one resource. The real gate is not effort but lifecycle: the repository is archived, with 57 stars, zero dependents, and a single maintainer, so the nova constraint in its composer.json is frozen and no upstream will widen it for a future Nova major. Feasibility therefore reduces to a one-day spike against our exact Nova major — install, render a resource form, save, reload, confirm the value round-trips without drift — and a named internal owner. If the spike passes, the work is a few days; if it fails, a thin owned field (Flatpickr plus Intl.DateTimeFormat, roughly 150–300 lines) is comparable effort with materially less permanent risk.

Technical risk. Three risks dominate, in order. First, asset-pipeline mismatch: Nova 4/5 moved to Vite-built Vue 3, and fields of this vintage are frequently Mix/Vue 2 — the failure mode is silent, with the picker degrading to a plain text input that nobody notices until malformed dates are already in the database. A browser-level smoke test (Dusk/Playwright asserting rendered output and a save/load round-trip) is the only credible mitigation. Second, unowned maintenance: archived means no security patches and no Nova-major tracking, so budget roughly half a day per Nova major plus ad hoc picker/Vue bumps, and treat the fork as a maintained dependency with a watchlist entry. Third, trusting the client's formatted string: a locale picker is presentation only, so server-side date/date_format validation and a datetime cast are non-negotiable, and storage must stay ISO-8601/UTC to avoid the classic off-by-one-day and DST drift.

Key questions.

• Do we hold a Nova license, and is the field's nova constraint actually satisfied by our installed major?
• Which single resource and which editor locale is the pilot — and has someone verified the request payload and the DB column after a save?
• Who is the named owner of the internal fork, and where does it sit on the maintained-dependency watchlist?
• Are locale and storage conventions (display locale from user, UTC in the column) documented in the repo, or is this tribal knowledge?
• Have we explicitly drawn the scope boundary with stakeholders: this fixes date entry and display, not timezones, ranges, recurrence, DST, or business-day logic?

Integration Approach

Stack fit. Requires Laravel plus a licensed Nova installation on a supported PHP version, with the PHP Intl extension present — confirm that on the runtime image as part of the spike, since it is a hard dependency rather than a soft one. The package slots in at the field-class layer only: it composes with existing Eloquent casts, form requests, and Nova authorization without touching them. Everything else in the stack — API layer, customer-facing surfaces, queues, jobs — is unaffected. If we are not on Nova, stop the evaluation and look at Filament, Livewire, or plain Blade with a maintained JS date library instead.

Migration path. There is no data migration. The pattern is additive and reversible: point one existing datetime column at the new field on one Nova resource, verify round-trip fidelity, then expand resource by resource. Never adopt globally on day one. Critically, the value already in the column is unchanged — the package changes how it is rendered and entered, not how it is stored — so rollback is a one-line field swap back to Nova's native DateTime. Two decisions in the PRD make this safe: display locale derives from the authenticated user (auth()->user()->locale) rather than config('app.locale'), and the server validates a strict format (date_format:Y-m-d\TH:i:s\Z) so a localized string can never be persisted verbatim.

Compatibility. Verified by spike, not by reading constraints — the constraint is frozen and therefore tells us what was true, not what is true on our version. Check the compiled bundle header in dist/ for Mix/Vue 2 versus Vite/Vue 3, and inspect the field class for its make() signature, exposed IntlDateFormatter options, and whether resolve()/fill() normalize values before they reach the model. Pin Nova, PHP, and Node versions in CI, and pin a browser version for the smoke test — headless Chromium builds can ship reduced ICU data and fall back to a default format, which makes locale assertions flaky if left unpinned.

Sequencing.

1. Spike (≈1 day, timeboxed): install, render one resource form, save, reload, inspect payload and DB column. Hard stop if it fails.
2. Wrap: subclass the field as App\Nova\Fields\LocalizedDateTime so every resource references our class and the replacement point is one file.
3. Pilot: one resource, one non-en-US editor, one sprint of observation. Keep it off the highest-traffic admin screens to limit blast radius.
4. Fork-and-own: consume via a VCS repository entry rather than Packagist, rebuild assets under our toolchain, tag ^1.0, add a smoke test.
5. Expand: additional resources only after the pilot is clean, with the fork already owned and watchlisted.

Vendor posture. Consume the fork from an internal Git namespace (acme/nova-intl-datetime) with a repositories entry of type: vcs. This removes any dependency on the archived upstream, makes the swap point explicit, and lets us rebuild assets against our own Node/Vite versions without patching a vendor directory.

Operational Impact

Maintenance. This is the dominant cost and it is permanent. Archived means we are the maintainer from commit one: no upstream security patches, no Nova-major compatibility work, no PHP or Laravel upgrade support. Realistic budget is roughly half a day per Nova major plus ad hoc Vue/picker bumps, concentrated in one place because we standardized on a single canonical field. That concentration is the main operational argument for adopting across multiple Nova tools — it converts a scattered per-project upgrade tax into one owner, one watchlist entry, and one smoke test. Without a named owner the field becomes a bus-factor risk on the next upgrade.

Support. No commercial support, no community safety net — 57 stars and zero dependents means any bug we hit, we own. Debugging is source-reading, not web-searching: grep the field class and the compiled bundle. The extension surface is deliberately small — the field class and the Vue component — with resolve(), fill(), and component() as the only meaningful override points; anything beyond formatting options lands in our subclass or not at all. Support load from users should be near zero, since locale-correct display reads as "it just works," but the reverse is true of silent failures, which generate no tickets and instead surface later as data cleanup.

Scaling. Runtime cost is negligible — one input plus an Intl call per render, no queue work, no N+1, no profiling warranted. Cost scales with Nova majors, not with users or records. The genuine scaling trap is organizational: the same field deployed across many internal tools without an owner multiplies the upgrade surface, whereas the same field behind one forked package in one namespace scales cleanly. Spend the optimization budget on the ownership plan, not on performance.

Failure modes. Enumerated, with mitigations and detection:

• Silent asset-pipeline mismatch — the picker degrades to a plain text input; bad data arrives quietly. Detect with a browser smoke test asserting rendered output and save/load round-trip; mitigate by pinning Nova/Node/browser and checking dist/ for Mix vs. Vite.
• Localized string persisted verbatim — 03/04 reaches the DB as text or as the wrong date. Mitigate with server-side date/date_format rules plus a datetime cast; detect by inspecting the request payload and column after a save.
• Timezone/DST off-by-one day — localized display leaks into storage. Mitigate by storing UTC and rendering in the user's timezone; detect with a test running under a non-UTC APP_TIMEZONE.
• Nova major upgrade breaks the field — no upstream fix exists. Mitigate with the internal fork, a smoke test in CI, and a scheduled re-verification on every Nova bump before upgrade.
• Reduced ICU data in CI — headless browser falls back to a default format, making assertions flaky or falsely green. Mitigate by pinning browser/Node versions and asserting exact strings.
• Ambiguous entry reduced but not eliminated — locale ordering is fixed; ranges, recurrence, business-day rules, and "is this date in the past in the user's timezone?" are untouched. Set this expectation explicitly so nobody treats the picker as scheduling logic.

Ramp-up. Near zero for engineers — drop the field into a fields() method, add rules, sortable(), done. The real onboarding artifact is a short README in the fork documenting locale resolution and storage conventions (display locale from the user, UTC in the column, ISO-8601 on the wire), plus the smoke test as executable documentation. Without it, the conventions become tribal knowledge and the next Nova upgrade is relearned from scratch. For stakeholders, the ramp-up is conceptual rather than technical: this is internal admin tooling, MIT-licensed with no cost, worth a few days of engineering — and worth using only as a scoped reference implementation or a forked internal accelerator behind a passing compatibility spike, never as standing infrastructure and never on a customer-facing surface.