Symfonyjdate Laravel Package

Technical Evaluation

What changed in v1.1.12. The release note is a single line: "Fixed Twig extension bug in the previous release." That is a patch-level bugfix confined to the Twig extension — the Symfony view-layer glue. It touches none of the Jalali↔Gregorian conversion arithmetic, adds no PHP 8 compatibility work, no Composer constraint changes, and nothing Laravel-facing. For our purposes the integration surface is unchanged.

What it does change: our provenance assumptions. The prior assessment stated the package was "abandoned since 2015-03-30" with no commits in 10+ years. A v1.1.12 patch — and a version number implying at least twelve prior patch releases — is inconsistent with that claim. Either the upstream is more active than the repository metadata suggested, or the version/date metadata is unreliable. Both possibilities matter: an active upstream is a better maintenance story than we assumed, while unreliable metadata is a worse trust signal. This must be re-verified (last commit date, tag dates, issue-tracker responsiveness, whether a maintainer responds to a test issue) before the assessment is finalized. Do not carry the "abandoned" conclusion forward unexamined, and do not carry the opposite either.

What it does not change: the architecture verdict. This remains a Symfony 2 bundle, not a Laravel package, despite the symfony_persia/symfonyjdate vendor name. Integration surface is still SymfonyJDateBundle, a DependencyInjection/*Extension, services.yml/XML loading, and a Twig extension. The fact that the most recent engineering effort went into the Twig extension rather than the core algorithm or PHP modernization is itself informative: upstream's investment is in the Symfony integration path we intend to discard, not in the portability work we would need.

Architecture fit (Laravel). Poor as-shipped, unchanged by this release. Laravel expects illuminate/support service providers, facades, config publishing, and Composer 2-compatible PSR-4 autoloading. A Symfony 2 bundle provides none of these. Adapting means either (a) registering bundle classes in a custom ServiceProvider while carrying dead Symfony DI code — now including a Twig extension we cannot use — or (b) forking the conversion class into first-party code. (b) remains the only defensible option.

Integration feasibility. Still blocked on dependency resolution, not code. A Symfony 2-era bundle will almost certainly declare symfony/symfony: ~2.x and php: >=5.3 constraints. Under Composer 2 with Laravel 10/11 (PHP 8.1–8.3), composer require will fail or require --ignore-platform-reqs plus manual constraint surgery. A Twig-extension bugfix does not move these constraints. Even where source is plain PHP, it was written against PHP 5 semantics: no scalar type hints, no return types, likely each()/create_function()/dynamic properties that PHP 8.2 deprecates.

The 2038 claim. Unchanged and still the package's one piece of genuine engineering value. Integer calendar arithmetic rather than Unix-timestamp arithmetic is the correct approach for Jalali date range. It also means the class probably cannot implement DateTimeInterface, so Laravel's Carbon ecosystem, model casts, validation rules, and now() helpers will not interoperate. Expect a bespoke value object with its own formatting vocabulary.

Technical risk. High, and now with a provenance caveat rather than a provenance conclusion:

• Maintenance status uncertain — v1.1.12 contradicts the "no commits since 2015" signal. Re-verify before relying on either characterization.
• Near-zero community validation — 10 stars, 0 dependents. Regardless of commit recency, no observable third party runs this in production; failures are ours to discover.
• License ambiguity — repositories of this vintage frequently ship with no LICENSE file. Unlicensed code is all-rights-reserved by default; confirm before copying anything into our codebase, even as a fork.
• Algorithmic correctness unverified — Jalali leap-year rules, the 33-year cycle approximation, Persian digit rendering, and timezone boundaries. A silent off-by-one-day error in a billing or reporting date is a high-severity business defect.
• Scope drift risk — a release that fixes only the Twig extension tells us nothing about whether the conversion class has ever been audited. Absence of fixes is not evidence of correctness.

Key questions for the requester:

1. What is the actual requirement — Jalali display formatting, Jalali parsing/validation, or full Jalali date arithmetic and storage? That determines whether we need 50 lines or a maintained library.
2. Do we need Carbon interoperability (Eloquent casts, diffForHumans, validation rules)? If yes, this package is disqualified regardless of its release cadence.
3. Is the 2038 requirement real (long-dated contracts, pension or amortization schedules) or inherited from the package description?
4. What is the actual last-commit date and maintainer responsiveness, given v1.1.12 contradicts our prior metadata? Who holds the license, and can we get written permission to fork?
5. Is there an existing house standard for Persian dates in another service?

Integration Approach

Stack fit. No native fit. Realistic options, unchanged by a Twig bugfix:

Recommendation. Unchanged: do not add this as a dependency. Run a two-day spike benchmarking maintained alternatives against this package's arithmetic across 1900–2200, including Persian leap years 1399, 1403, 1408, against an authoritative reference table. If a maintained library matches, use it and close the ticket. If only this package satisfies the >2038 requirement, extract its conversion class into app/Support/Jalali/ or a private Composer package, preserving the original copyright and license header, and own it. Note that v1.1.12 does not alter this calculus — the reusable asset is still one or two classes, and the release touched none of them.

Migration path (assuming extraction):

1. Vendor the conversion class into a private namespace; strip all Symfony bundle classes, DI extensions, services.yml, and the Twig extension. If the v1.1.12 fix indicates the Twig layer is the actively maintained part, that is further reason to leave it behind entirely.
2. Add strict types, return types, and PHPUnit coverage across a fixed reference table before any refactor — the tests are the deliverable that de-risks the fork.
3. Wrap in a thin JalaliServiceProvider exposing a Jalali facade and jalali() helper; bind config for default timezone (Asia/Tehran) and digit rendering.
4. Add Eloquent cast support only if needed — scope as a separate story, since the DateTimeInterface gap is real work.

Compatibility. Target PHP 8.1+ and Laravel 10/11. Assume PHP 8.2 dynamic-property and PHP 8.4 implicit-nullable deprecations will surface; budget a cleanup pass. Avoid --ignore-platform-reqs as a permanent posture.

Sequencing. Provenance re-verification (commit dates, license, maintainer response) → correctness validation → extraction (if justified) → service provider → reference-date tests → feature flag → migrate formatting call sites. Ship behind a flag so a date-rendering regression rolls back independently of a deploy.

Operational Impact

Maintenance. Effectively transfers to us on fork. The open question from v1.1.12 is whether an upstream maintainer is actually responsive — if a real maintainer exists, we can consume patches on the Symfony side and track security reports, which modestly improves the fallback option. If the release metadata is stale or the project is a slow trickle of Twig fixes, plan as before: no upstream to merge meaningful work from, and every PHP major, tzdata change, or calendar-rule clarification is our ticket. For a single conversion algorithm, 1–2 days per year is acceptable if well-tested; it becomes unacceptable once we layer Eloquent casting, localization, or digit variants on top.

Support. Still no SLA, no CVE process we can point to, and no evidence that issues get triaged promptly. Open a test issue or PR as part of the provenance check — the response (or silence) over two weeks tells us more than a version number does. Name a platform-team owner before merge; an unowned vendored date library is a latent incident.

Scaling. Performance is a non-issue — integer arithmetic, nanoseconds; cost is dominated by string formatting even at thousands of dates per request. The scaling concern is correctness at scale: a one-day error silently corrupts every daily aggregate, invoice due date, and reporting period. Cache formatted strings at the presentation layer rather than re-converting.

Failure modes to instrument and test:

• Timezone boundary — Asia/Tehran is UTC+3:30 with no DST since 2022. Code compiled against older tz data may carry stale DST transitions and shift dates by an hour around Nowruz. Pin tzdata; test March 20–21 explicitly. A Twig-extension patch is no evidence this was addressed.
• Persian leap-year edge — the 33-year cycle approximation drifts against the astronomical rule over centuries. Test 1399/1403/1408 and, for the 2038+ requirement, 1450 and 1500.
• 32-bit / integer overflow — verify on any 32-bit target in the fleet; escaping this is the package's premise, so confirm it actually does.
• Digit rendering and locale — Latin vs. Persian-Indic digits in API output is a frequent client-side bug source; make it explicit config, never implicit.
• Silent null on invalid input — old PHP date code often returns false/null rather than throwing. Wrap in an exception-throwing adapter so failures are loud.

Ramp-up. Low for a PHP developer comfortable with calendar math: about half a day to read, half a day to write reference-table tests. The real cost is trust — someone must independently verify output against an authoritative Jalali calendar before we let it format customer-facing dates. v1.1.12 neither builds nor erodes that trust; it is a fix to a component we would not ship. Treat both the 0.2 quality score and the version-number/commit-date inconsistency as signals to verify rather than to conclude.