Nova Persian Date Field Laravel Package

Technical Evaluation

• Architecture fit: This is a narrow Laravel Nova field package, not a general Laravel date library. It fits only if the product already uses Laravel Nova for internal/admin tooling and has a concrete requirement to display or input dates in the Persian/Jalali calendar. The TPM leverage is operational: reduce manual Gregorian-to-Jalali conversion for Persian-speaking admins, improve input accuracy, and keep database values in standard Gregorian format. If Nova is not in the stack, or users do not need Jalali presentation, the package has near-zero architectural value.
• Integration feasibility: Likely feasible as a Composer package registered as a Nova field on selected resources. Typical work is install, register the field, publish assets/config if required, and verify round-trip conversion between Jalali input and Gregorian persistence. The main feasibility gate is Nova version compatibility, not Laravel itself. With 2 stars and 0 dependents, there is little community validation; treat it as a candidate for a time-boxed spike, not a pre-approved dependency.
• Technical risk: The highest risks are Nova major-version coupling, low adoption, single-maintainer continuity, frontend asset behavior, and date correctness. Jalali conversion must be tested around leap years, month boundaries, timezone offsets, daylight-saving transitions if times are included, nullable fields, min/max constraints, and validation failures. The package should only affect presentation/input; persisted values should remain Gregorian UTC/database datetime. If it stores Jalali strings or shifts timezones, that is a redesign-level concern.
• Key questions:
  • Which Nova major versions and Laravel/PHP versions are supported?
  • Does it store Gregorian values correctly, or does it persist Jalali-formatted strings?
  • How does it handle timezones, DST, nullable values, and date-only vs datetime fields?
  • Are frontend assets prebuilt and publishable, or does adoption require Node/build tooling?
  • Does it support Nova index/detail formatting, filters, validation, and inline editing?
  • What conversion library or algorithm is used, and is it tested against known Jalali/Gregorian boundary cases?
  • What is the license, security posture of JS dependencies, and maintainer responsiveness?
  • Is there a fallback plan if a Nova upgrade breaks the field?

Integration Approach

• Stack fit: Best fit is a Laravel + Nova admin application with MySQL/PostgreSQL datetime columns and a Persian-speaking operations team. It is not a fit for public-facing APIs, customer SPA forms, or non-Nova admin panels. Use it only on admin resources where Jalali display materially improves operator accuracy or speed.
• Migration path: Start with no schema change if existing columns already store Gregorian datetimes. Add the field to one low-risk Nova resource, pin the Composer version, publish required assets, and compare displayed Jalali values against known Gregorian fixtures. Avoid broad rollout until round-trip conversion, timezone behavior, and validation are proven. If existing data was manually entered in Jalali or local time, plan a separate data-quality audit rather than assuming the package can normalize it.
• Compatibility: Confirm the exact Nova, Laravel, PHP, and database matrix before installation. Verify whether the package ships compiled assets or requires a frontend build. Check browser support for the admin user base and confirm locale/timezone configuration matches Nova and application settings. Because the package is low-adoption, treat compatibility as unproven until tested in the target environment.
• Sequencing:
  1. Confirm the business requirement and identify the first admin screen where Jalali input is needed.
  2. Verify Nova/PHP/Laravel compatibility and license/security acceptability.
  3. Install in a development branch and register the field on a sample resource.
  4. Test Gregorian persistence, Jalali display, timezone handling, nullable values, validation, and boundary dates.
  5. Test Nova index/detail/filter behavior if those surfaces are in scope.
  6. Pilot with a small group of Persian-speaking admins and capture conversion or UX defects.
  7. Decide: adopt with version pinning, fork with internal ownership, or fall back to native Nova datetime fields plus a custom formatter/converter.

Operational Impact

• Maintenance: Expect internal ownership. With 2 stars and 0 dependents, the package should be pinned and tracked, but the team must be prepared to fork or replace it if Nova upgrades break compatibility. Add regression tests for Jalali/Gregorian conversion and document the supported version matrix. A recent release date helps, but low adoption means maintenance risk remains material.
• Support: There is no meaningful community support base or SLA. Internal Laravel/Nova developers will need to own integration issues, asset publishing problems, and frontend defects. Establish an escalation path to a fork before production use, especially if the field appears on high-volume operational screens.
• Scaling: Runtime scaling is not a major concern because this is admin-only UI. The practical scaling limit is operational breadth: rolling the field across many Nova resources increases exposure to inconsistent behavior, timezone bugs, and upgrade breakage. Keep the initial footprint small and expand only after proven round-trip correctness.
• Failure modes: Likely failure modes include Nova upgrade incompatibility, missing or stale published assets, JavaScript errors blocking admin forms, off-by-one date conversion, timezone/DST shifts, incorrect handling of null or partial dates, validation bypass, index/detail display mismatch, and unmaintained frontend dependencies. The most damaging failure is silent date corruption, so persistence tests should be mandatory.
• Ramp-up: Low for developers already familiar with Laravel Nova fields; moderate for teams unfamiliar with Jalali calendar semantics and Persian UX expectations. Admin users may ramp quickly if the picker is familiar, but QA must include Persian-speaking users and known boundary dates. Overall recommendation: use only as a scoped, version-pinned admin enhancement after a short technical spike; do not treat it as a platform-critical dependency.