Filament Jalali Datetimepicker Laravel Package

Technical Evaluation

Architecture fit. Filament is a TALL-stack admin framework: form fields are Livewire-rendered PHP components with an Alpine/JS front end. This package is a sibling of Filament's DateTimePicker that swaps the calendar front end for a Jalali one and converts to/from Gregorian for storage. That is a narrow, well-bounded seam — a presentational concern layered over a datetime column. It does not touch the domain model, persistence layer, or API surface. Architecturally it is low-coupling by design. Fit is strong only where the admin audience is Persian/Dari-speaking; it is not a global default.

Integration feasibility. High on the happy path: composer require, register the plugin or swap the field class, done. Real feasibility is gated by version compatibility, not effort.

Technical risk.

• Archived — the dominant risk. No upstream fixes, no security response, no path to Filament v4. Every future Filament major becomes our patch.
• 23 stars, single maintainer — low community validation; edge cases have not been pressure-tested by a crowd.
• Calendar correctness is a domain hazard. Jalali leap-year rules, Esfand 29/30, variable month lengths, and the 2022 abolition of DST in Iran (Asia/Tehran) all produce off-by-one-day bugs that are silent and user-visible.
• Storage contract. The DB must keep Gregorian/UTC. If the component ever persists Jalali strings or local-time values, that is a hard-to-reverse data integrity failure.
• Front-end dependency. Whatever JS datepicker it wraps carries its own RTL, accessibility, CSP, and browser-support posture.

Key questions to verify against the repo before committing.

• Which Filament and Livewire majors does composer.json constrain? Does it cover our pin and our next upgrade?
• Does it convert on save (Gregorian to DB) and on load, and in which timezone?
• Does it cover table columns, filters, and inline-editable cells, or only form fields?
• What is the underlying JS datepicker — license, maintenance, CSP behavior?
• Is picker-mode parity complete (date-only, time-only, datetime, ranges)?
• Do validation rules and minDate/maxDate respect Jalali input?
• Is there a maintained alternative — a Filament Jalali plugin, or a generic datepicker plus a Morilog/Verta conversion layer — that avoids an archived dependency?

Integration Approach

Stack fit. Laravel + Filament v3 + Livewire 3. If we are on Filament v4, assume incompatible until proven otherwise — the DateTimePicker internals changed. No database, queue, or runtime footprint.

Migration path. Because it is MIT and archived, treat it as a source dependency, not a package dependency. Vendor it into app/ or an internal namespace (or a private fork) on day one. That converts "unmaintained third party" into "small internal component we own," which is the only sustainable posture. Two engineers can read the entire thing in an hour.

Compatibility. Pin the exact version. Add a CI job that installs the package against our pinned Filament version so a framework composer update cannot silently break date entry. Track Filament release notes for DateTimePicker changes as an early-warning signal.

Sequencing.

1. Spike (~0.5 day). Install on a scratch branch, render date and datetime fields, confirm Gregorian values land in the DB and round-trip.
2. Correctness tests (~1–2 days, the deliverable that matters). Round-trip fixtures at Nowruz, Esfand 29/30 in leap and non-leap years, 1403, midnight boundaries, and Asia/Tehran offsets.
3. Isolate. Wrap it as App\Forms\JalaliDateTimePicker so no call site references the vendor class. One file to patch at upgrade time.
4. Gate. Roll out behind a locale check so only FA-locale tenants get the Jalali UI; everyone else keeps the Gregorian field.
5. Fork if step 1 or 2 fails. MIT permits it and the surface area is small.

Operational Impact

Maintenance. The dominant cost. Archived means maintenance is ours by default; budget it as "we own a Filament form component." Realistically a few days per Filament major, near zero in between. Assign a named owner — an unowned archived dependency in an admin panel is how you get a broken date field on a Monday.

Support. None. No maintainer response, no CVE channel. Mitigated by vendoring (we can patch in hours) and by keeping the blast radius to admin UI only — this must never become the sole write path for timestamps.

Scaling. Negligible. Client-side rendering, one instance per field, no server load, no query change, no cache concern. Not a scaling consideration at any plausible tenant volume.

Failure modes, ranked.

• Silent off-by-one-day on save (leap-year or timezone) — highest severity, corrupts business data. Mitigated by round-trip tests and Gregorian-only storage.
• Filament upgrade breaks the field — loud, cheap to fix (form fails to render).
• JS datepicker CSP or asset-pipeline regression — loud, cheap.
• Unpatched issue in the underlying JS library — quiet, severity depends on the library.
• Non-Persian users shown an unreadable calendar — mitigated by locale gating.

Ramp-up. Low. A mid-level Laravel developer is productive in under a day; the code is thin. The real ramp is calendar domain literacy — whoever owns the tests needs to know why Esfand 30 exists some years. That is a fixture and training cost, not a code-reading cost.

Recommendation. Adopt only if the product genuinely requires a Persian admin UI and we are on Filament v3. Adopt as a vendored fork, behind a locale gate, with correctness tests. Do not adopt blind from Packagist given the archived status — the 0.0875 score is consistent with "small, unmaintained, single-maintainer," which is precisely what forking mitigates. If we are on or planning Filament v4, budget the rewrite now rather than discovering it mid-upgrade.