Nova Persian Date Field Laravel Package

Product Decisions This Supports

• Market expansion into Persian-speaking segments (Iran, diaspora, regional B2B). If our roadmap includes an Iranian market launch or Persian-language admin tooling, Jalali (Shamsi) date entry is a table-stakes localization requirement, not a nice-to-have. This package is a candidate to satisfy that requirement inside Laravel Nova.
• Build vs. buy vs. adopt for calendar localization. A Nova field is small enough to build in-house on top of an established Jalali conversion library in roughly 1–3 engineering days. This package is the "adopt OSS" option; the decision hinges on whether the time saved outweighs the maintenance/bus-factor risk of a 2-star dependency.
• Admin-panel scope decisions. Because it is a Nova-specific field, choosing it implicitly confirms Nova as the internal tooling layer for the Persian market. If we are uncertain about staying on Nova (it's a paid, first-party product with its own licensing cost), this package should not be a factor in that decision.
• Localization roadmap sequencing. Adding Jalali input for admin users is a different problem from Jalali display in customer-facing apps, PDF invoices, exports, and reporting. This package solves only the former; it should not be treated as the whole localization workstream.
• Compliance and operational correctness. Regions using the Jalali calendar expect dates on invoices, statements, and internal records to align with local convention. A field-level fix reduces manual conversion and data-entry error in back-office workflows.

When to Consider This Package

Consider it when all of the following hold:

• We are already running Laravel Nova in production and have no near-term plan to migrate off it.
• Persian-speaking internal users are entering or editing dates in the admin, and Jalali entry is a real pain point (not just a display preference).
• The requirement is narrow — a datetime picker field — and does not need recurring-event logic, complex timezone handling, or Hijri/other calendar support.
• We can vendor/fork the package into our repository or pin it, so upstream abandonment is not a blocker.

Look elsewhere when:

• We are not on Nova. The addressable value is zero outside Nova; a general Jalali conversion library plus a custom frontend component covers broader needs.
• We need more than admin input. Customer-facing date rendering, multi-calendar support, or locale-aware formatting across the product argues for a foundational date/localization layer, not a single field package.
• Maintenance confidence is required. Two stars, zero dependents, and a single maintainer is a thin signal. For anything long-lived or revenue-critical, budget for owning the code.
• The score reflects reality. An overall score around 2.3 against an opportunity score of 6 reads as "real need, weak execution/maturity" — validate the code, test coverage, and Nova version compatibility before committing.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost enabler for serving Persian-speaking users in our internal admin tooling. It addresses a genuine localization gap — Jalali date entry — that would otherwise cost engineering time to build. The financial exposure is minimal, but so is the strategic weight: treat it as a tactical component, not a platform bet, and fund a fallback plan (fork or in-house build) as part of adoption.

To engineering: A Nova field package for Persian datetime input. Tiny dependency, thin surface area, easy to vendor. The tradeoff is explicit: near-zero integration cost versus a 2-star, single-maintainer upstream with no dependents. Recommend we pin the version, review the source, and be prepared to own it. If we need Jalali dates outside the admin panel, this package is not the answer — plan a shared localization utility instead.