verta: a Jalali calendar date layer for Laravel built on PHP DateTime

A DateTime subclass that speaks the Solar Hijri calendar

verta is described as a package for changing between the Solar calendar and the Gregorian one, with helper functions for working with date and time. The README states that it extends the PHP DateTime class and is compatible with the Carbon package, and it was created by Nasser Hekmati under the MIT licence. That framing decides the audience. This is not a date library you adopt instead of Carbon, it is a calendar layer that sits alongside Carbon and the native DateTime, and the audience is a Laravel developer whose users expect the Jalali calendar, which is how dates are written and spoken in Iran and Afghanistan. The topics the project carries are consistent with that: jalali, shamsi, gregorian, datetime, carbon, laravel and persian-datetime. The package is on Packagist as hekmatinasser/verta, and the full documentation, including an English version, lives on a GitHub Pages site.

One install command and a version table tied to Laravel

Installation is a single Composer require, and the package is auto discovered by Laravel in the usual way.

composer require hekmatinasser/verta

The README then gives a compatibility table that is the important operational detail: Laravel 8.0 pairs with package version 8.0, Laravel 9.0 with 8.2, Laravel 10.0 with 8.3, Laravel 11.0 with 8.4, and Laravel 12.0 with 8.5. The release history adds a v9.0 tag published for Laravel 13 on 2026-05-08, and the last push to the repository was on that same date, with the previous releases v8.5 in March 2025 and v8.4.1 in April 2024. So the versioning tracks Laravel's own major releases rather than being independent, which means your upgrade path is coupled to your framework upgrade, and a team on an older Laravel is pinned to an older line of this package.

Instantiating a Jalali date, and converting in both directions

The quick view section shows the whole surface in a dozen lines, and it starts with a global helper. Calling verta() with no argument returns the current moment in Jalali, and passing a Gregorian date string converts it. The reverse direction goes through the parse method on the Verta class, and the datetime() call takes a Jalali value back to a Gregorian string.

echo verta(); //1401-05-24 00:00:00

echo verta('2022-08-15'); //1401-05-24 00:00:00

echo Verta::parse('1401-05-24 14:12:32')->datetime(); //2022-08-15 00:00:00

The Carbon bridge is the other half of the story, and it works in both directions. A Carbon instance, which is what now() returns in a Laravel application, converts with toJalali(), and a Verta instance converts back with toCarbon(). That compatibility is what makes the package usable inside an existing Laravel codebase rather than something you bolt onto the side, since most application code is already working with Carbon objects and models.

Getters, setters and fluent setters on the date parts

Once you have a Verta instance, the parts of the date are read and written like properties. The getter example reads the Jalali year directly off the object, and the setter example assigns to it. There is also a fluent setter for setting several parts at once, here a time string.

$v = verta(); // 1396-03-14 14:18:23
echo $v->year; // 1396

$v = verta(); // 1396-03-14 14:18:23
echo $v->year = 1395;

$v = verta(); // 1396-03-14 14:18:23
echo $v->setTimeString('12:25:45');

The same pattern covers modification, boundaries, comparison and difference. The modification example adds weeks, the boundary example moves to the start of a week, the comparison example checks a date against another with gte, and the difference example computes a difference in months between two dates. Each of these is documented as a group in the online documentation, with the README linking to the relevant anchor for the full method list rather than enumerating them.

Formatting, humanised differences and locale switching

Formatting follows the familiar format() convention, and a separate formatWord() call produces a spelled out version using the Persian month and day names, so a formatted date reads as text rather than digits. There is also a dedicated common format helper that produces the slashed Jalali datetime layout.

echo verta()->format('Y.m.d'); // 1401.05.24

echo verta()->formatJalaliDatetime(); // output 1395/10/07 14:12:25

A humanised difference helper turns a relative date into readable text, and the example shows a date thirteen months back rendered as a year ago. The localisation mechanism is a single static call, Verta::setLocale('ar'), which sets the language used for formatting dates. The README does not enumerate the available locales, so the set of languages you can switch into has to be checked in the online documentation before you commit to it.

Date validation and the Laravel request rule

The validation section is where this package earns its keep in a real Laravel application, because a form that accepts a Jalali birth date needs to reject a date that does not exist, such as 31 Esfand in a common year. The static helper checks calendar facts, and the leap year check is the example given.

echo Verta::isLeapYear(1394); // false

For request validation the package registers a Laravel validation rule, used the way any other rule is used in a rules array, here alongside the required rule on a birthday field.

'birthday' => ['required', 'jdate_before_equal']

The rule name follows the jdate prefix, and the documentation links to a section on Laravel validation. The README's example shows the before_equal variant, which implies a family of comparison rules around it, but the full set is only listed in the online documentation. The repository itself carries a tests/ directory and a phpunit.xml.dist, along with a .php_cs.dist.php style configuration and an .editorconfig, so the package ships with a test suite and a code style definition.

Where verta is the wrong tool

Several boundaries are worth naming. First, this is a calendar library, not a localisation framework. The README lists a single locale switch, and there is no documented support for a month names table across many languages, so a product that needs Persian, Dari, Kurdish and English date strings with translated month names will need to supply that itself. Second, the version coupling is real: package versions track Laravel major versions, and the compatibility table in the README stops at Laravel 12, so a team on Laravel 13 has to read the release notes to see whether v9.0 behaves as expected. Third, the README documents no rollback, no changelog policy, and no deprecation schedule, so a breaking change in a minor version is possible in principle. The comparison with Carbon is a fair one to keep in mind: Carbon is a general purpose date library, whereas verta is specifically the Jalali layer, so adopting verta means adding a second date abstraction to a stack that already has one, rather than replacing Carbon.

Editorial conclusion

Adopt verta if your Laravel application has to display, parse or validate dates in the Solar Hijri calendar, and you want one dependency that handles conversion, formatting and request validation. Do not adopt it if your dates are Gregorian only, or if you need a full localisation stack with translated month names across many locales, because the localisation surface here is a single setLocale switch. Verify first that the version you install matches your Laravel major version, because the package releases track Laravel releases and the compatibility table in the README stops at Laravel 12.

Frequently asked questions

Official sources

1. hekmatinasser/verta on GitHub
2. License: MIT
3. Project website
4. README
5. Releases