- What does dpsoft/nova-persian-date actually do?
- It is a Laravel Nova field that lets admin panel operators pick and read dates in the Jalali (Shamsi) calendar while the value is converted to Gregorian for persistence. Implementation-wise it is a single-purpose Nova form component: one Vue input plus a PHP Field subclass. It is not a general Jalali conversion library, formatter, or API serializer, so it provides nothing outside a Nova resource.
- How do I install nova-persian-date in Laravel Nova?
- Run composer require dpsoft/nova-persian-date, then register the field class in your Nova resource's fields method like any other Nova field. The integration surface is only a few lines per resource, so the mechanical setup is trivial. Check the package's composer.json constraint against your installed Nova major first, because the metadata alone does not prove compatibility.
- Is nova-persian-date compatible with Laravel Nova 5 and Vue 3?
- That is unverified and the biggest gate on this package. The only release on record is dated 2023-07-26, which predates Nova 5 and its Vue 3 frontend and revised asset pipeline, so it is unlikely to render correctly without patching. Install it on a licensed staging Nova 5 environment and verify before scoping any work.
- Does nova-persian-date store Shamsi or Gregorian dates in the database?
- The correct behavior for this class of field is to persist Gregorian (ideally UTC) and convert to Jalali only at the presentation boundary, which is what the package intends. Confirm in the source that it does not round-trip a Jalali string into your date column. Storing Shamsi strings is a defect to reject at code review, not a configuration choice, because it breaks every downstream query, report, and API consumer.
- How does nova-persian-date handle timezones and daylight saving time?
- The package metadata does not document its timezone resolution, so check whether conversion uses app.timezone, UTC, or the browser's local zone. Midnight-boundary off-by-one errors and DST shifts are the most common failure mode for Jalali fields, and they fail silently rather than throwing. Submit a date near midnight from a non-UTC timezone in a test and assert the stored value before trusting it.
- Does the field work correctly with Nova sorting, filters, metrics, and CSV exports?
- This is not confirmed anywhere in the metadata and it is the ecosystem gap most likely to cause problems. If a sortable column resolves to the rendered Jalali string instead of the underlying Gregorian column, ordering will look plausible but be wrong. Test sorting, filter queries, and CSV or Excel exports against a known dataset on staging before rolling it out.
- Does nova-persian-date support DateTime and validation rules like nullable, after, and before?
- Not confirmed from the package metadata. A well-behaved Nova date field should apply nullable, after, and before to the underlying Gregorian value and should handle a time component alongside a date-only value. Verify both yourself, since rule handling and time components are easy to get subtly wrong in custom field implementations.
- How do I test a Nova field package in CI when Nova itself requires a license?
- You cannot run Nova's test suite or your own Nova feature tests on a public CI runner without a license. Plan for a private pipeline with credentials or manual verification on a licensed staging environment. The conversion logic itself can usually be unit tested in isolation without booting Nova, which is where you should put your leap-year and boundary-date fixtures.
- Is nova-persian-date safe to use in production?
- Silent date corruption is the dominant risk: timezone boundaries, Jalali leap-year rules (the 33-year cycle, not a simple modulo), and DST shifts all fail quietly, and wrong dates in financial or scheduling records are usually discovered months later. The package also has a single maintainer, roughly 8 stars, no dependents, and no release in about two years, so there is no community backstop. Confine it to internal back-office tooling for Persian-speaking operators and keep it out of any surface that clients consume programmatically.
- What are the alternatives to nova-persian-date?
- Given the small surface area of one field and one conversion concern, the realistic options are vendoring or forking this package and pinning it to your Nova major, or writing a thin custom Nova field on top of a maintained Jalali conversion library for both PHP and JavaScript. Either way, keep the architecture the same: store Gregorian UTC in the database and convert only at the presentation layer. If you need Persian dates in customer-facing views, APIs, or reports, you need a separate conversion layer regardless of which field you pick.