Product Decisions This Supports
- Regional market entry / retention (Iran, Afghanistan, and Persian-speaking diaspora): The core decision this enables is whether to support Jalali-calendar date entry natively inside an admin or back-office UI, rather than forcing users to mentally convert to Gregorian. For any product with Persian-speaking operators (ops staff, finance, logistics, clinic scheduling, HR), date entry is a daily-use surface — this is a usability decision with retention impact, not a cosmetic one.
- Build vs. buy for calendar logic: Jalali↔Gregorian conversion has real edge cases (leap-year cycle, month lengths, year-boundary handling, and RTL presentation) plus the integration work of binding it to a form component. Buying a picker that handles both calendars is materially cheaper than owning conversion correctness in-house, and the failure mode of getting it wrong is silent data corruption on stored dates.
- Filament v5 upgrade path: If the roadmap has a pending Filament v4→v5 move, availability of a dual-calendar field can be a genuine unblocker — teams frequently pin an admin framework version because one localized field type has no v5-compatible equivalent. Confirm whether this is an upgrade blocker or a new capability before sizing the roadmap impact; the answer changes the priority significantly.
- Localization strategy scope: Whether locale support is "translated labels" or "culturally correct input surfaces." A dual-calendar picker is evidence for the latter. If the org has committed to a localization OKR, this is a cheap, demonstrable artifact.
- Reporting and data-entry consistency: If downstream reports, exports, or compliance documents are expected in Jalali dates, capturing them correctly at the input layer avoids a conversion/backfill project later.
When to Consider This Package
Adopt when:
- You are building on Filament v5 specifically — the release is scoped to v5 and is not a general-purpose date library.
- You have Persian-speaking end users entering dates in an admin panel, not merely readers of localized content.
- You need both calendars concurrently (e.g., internal Gregorian reporting alongside Jalali-facing data entry), which is the differentiating part of the value proposition.
- You want the conversion logic outside your application code so it can be swapped or upgraded independently.
Look elsewhere or defer when:
- You are on Filament v3/v4, or not on Filament at all — a standalone Jalali date library plus a custom form field is the better path.
- Your need is localization breadth (RTL layouts, translated validation messages, number formatting, Hijri alongside Jalali). A single field type does not constitute a localization story; budget for the surrounding work.
- You need native mobile or public-facing web date input — this is an admin-panel component and will not transfer.
- You require a support contract, SLA, or vendor accountability — at v1.0.0 from a new package, that is not on offer.
Assessment confidence caveat: this evaluation is based solely on the v1.0.0 release note; no source, test coverage, issue history, or maintainer record was available. Before adoption, verify: conversion accuracy against known Jalali/Gregorian boundary dates, whether underlying conversion is a maintained dependency or reimplemented, timezone and storage behavior (confirm dates persist in a canonical format and conversion is presentation-only), and whether the maintainer has a track record on Filament plugins.
How to Pitch It (Stakeholders)
For executives — one paragraph: This is a small, low-cost component that lets our admin users enter dates in the Persian (Jalali) calendar while the system stores and reports in Gregorian, or displays both side by side. It removes a daily friction point for Persian-speaking operators and de-risks date data quality, since manual calendar conversion by users is a known source of bad records. It is a single form field in a Laravel/Filament admin panel — narrow scope, reversible, and not architectural. The main caveats are maturity (it is a brand-new v1.0.0 release) and that it only applies if we are on Filament v5. Recommendation: worth a short technical spike and a pilot in one admin screen, not a broad rollout commitment yet.
For engineering — the short version: Filament v5 form field providing Jalali and Gregorian date picking in one component. Scope is deliberately narrow — it is an input widget, not a localization framework, so pair expectations with the rest of the RTL/i18n workstream. Please assess before we commit: (1) what it uses for conversion and whether that dependency is maintained, (2) test coverage and edge-case handling at Jalali year boundaries and leap years, (3) how values are serialized and stored — we want canonical storage with presentation-layer conversion, and (4) Filament v5 API stability, since v5 is itself new and plugin breakage is likely during early minor releases. Treat as a contained dependency: wrap it in our own field or config layer so it can be replaced without touching feature code.