Nova Persian Date Laravel Package

Product Decisions This Supports

• Localization roadmap for Persian-speaking markets. If the product strategy includes Iran/Persian-speaking users, admin-side date entry in Jalali is a small but visible credibility signal. This package lets you ship that in Nova without bespoke engineering.
• Build vs. buy for a narrow UI concern. The scope is one Nova field (Jalali date input/display with Gregorian storage). Build cost is low but non-zero; buying/adopting costs nearly nothing. Default should be: adopt and vendor, do not build.
• Admin UX decisions around data entry. Supports deciding whether operators enter dates in Jalali or Gregorian, and whether the database stays Gregorian (it should). This is a UX/consistency call, not an architecture call.
• Roadmap sequencing. Because the dependency is isolated to Nova resources, it can be scoped as a small ticket inside a broader "Persian admin experience" epic (RTL layout, translated validation, localized number formatting) rather than its own initiative.
• Not a decision driver for: public-facing date display, API date formatting, reporting/timezone logic, or any non-Nova surface. Those need a separate decision (e.g., a Jalali conversion library used in application code).

When to Consider This Package

Adopt it when all of the following hold:

• You already run Laravel Nova in production and the field appears on Nova resources.
• You need Jalali (Shamsi) date input or display in the admin panel only, with Gregorian persistence.
• You are comfortable pinning and vendoring/forking the package — it is a micro-package (8 stars, 0 dependents, last release July 2023), so treat it as source you own rather than a maintained dependency.
• Your Nova major version is explicitly verified against the package's field API before committing.

Look elsewhere or build in-house when:

• You are not on Nova. Nova is commercial and licensed; this package is meaningless without it. Use a general Jalali conversion library in your app layer instead.
• You need active maintenance or security responsiveness. No release since mid-2023 and no dependent ecosystem means no upstream safety net. Fork it or write ~100 lines yourself.
• You need Persian dates outside the admin — public site, emails, PDFs, API responses, exports. This package does not solve that; pick a dedicated converter and standardize a formatting layer.
• Your Nova version has moved on (Nova major upgrades change field contracts). Verify compatibility or budget the port.
• You have complex date semantics — date ranges, recurring schedules, timezone-sensitive timestamps. A single date field won't cover these; scope a proper date-handling decision.

How to Pitch It (Stakeholders)

To executives: This is a tiny, near-zero-cost add-on that makes our admin panel feel native to Persian-speaking operators — a cheap credibility win if that market is on the roadmap. The risk is equally small: the package is a single UI field and is fully forkable, so there is no vendor lock-in and no meaningful maintenance exposure. It is a tactical enabler, not a strategic bet; do not count it as progress toward localization on its own.

To engineering: Adopt only if we're on Nova and only for admin-side Jalali entry, with Gregorian stored in the database. Vendor or fork it — it's 8 stars, zero dependents, and no release since July 2023, so we own it either way. Verify the field API against our Nova version first. Keep it strictly out of application/domain code; public-facing and API date formatting need a separate, deliberate solution. Estimated integration effort: hours, not days.