I encountered an off-by-one date error for the current Persian year 1404 SH (starting March 2025) when using persian-datepicker.
on
- Frontend Datepicker:
persian-datepicker v1.2.0
- Underlying Logic Library:
persian-date v1.1.0 (dependency of persian-datepicker)
The problem was when using the datepicker, dates within the Persian year 1404 SH were consistently displayed one day ahead of the correct date. For example, the date corresponding to Gregorian April 8, 2025 (which should be Farvardin 19, 1404) was being displayed and selected as Farvardin 20, 1404.
This issue appears directly related to the transition from the Persian year 1403 SH (a leap year where Esfand had 30 days) to 1404 SH. Backend date conversion functions were verified to be correct, isolating the problem to the frontend JavaScript libraries.
Through investigation and testing different configurations, the root cause appears to be the leapYearMode setting used during the persianDatepicker initialization.
When the datepicker was initialized either relying on the default settings or explicitly using leapYearMode: 'algorithmic', the off-by-one error occurred. The algorithmic calculation in persian-date v1.1.0 seems unable to correctly calculate the start date of 1404 following the 1403 leap year.
// PROBLEMATIC Configuration Example (Using 'algorithmic' explicitly)
$('.datepicker').persianDatepicker({
format: 'YYYY/MM/DD',
autoClose: true,
// ... other options ...
calendar: {
persian: {
locale: 'fa',
leapYearMode: 'algorithmic' // <-- This mode caused the issue for 1404
}
}
});// OR PROBLEMATIC Configuration Example (Relying on defaults)
$('.datepicker').persianDatepicker({
format: 'YYYY/MM/DD',
autoClose: true
// ... other options ...
// NO explicit leapYearMode set
});The issue was resolved by explicitly setting the leapYearMode to 'astronomical' during initialization. The astronomical calculation within persian-date v1.1.0 appears to handle the 1403/1404 transition correctly in this specific instance.
For users of persian-datepicker v1.2.0 (and its dependency persian-date v1.1.0) experiencing this off-by-one error for the year 1404 SH, the recommended solution is to explicitly configure the leapYearMode to 'astronomical' in the JavaScript initialization options.
I encountered an off-by-one date error for the current Persian year 1404 SH (starting March 2025) when using
persian-datepicker.on
persian-datepickerv1.2.0persian-datev1.1.0 (dependency ofpersian-datepicker)The problem was when using the datepicker, dates within the Persian year 1404 SH were consistently displayed one day ahead of the correct date. For example, the date corresponding to Gregorian April 8, 2025 (which should be Farvardin 19, 1404) was being displayed and selected as Farvardin 20, 1404.
This issue appears directly related to the transition from the Persian year 1403 SH (a leap year where Esfand had 30 days) to 1404 SH. Backend date conversion functions were verified to be correct, isolating the problem to the frontend JavaScript libraries.
Through investigation and testing different configurations, the root cause appears to be the
leapYearModesetting used during thepersianDatepickerinitialization.When the datepicker was initialized either relying on the default settings or explicitly using
leapYearMode: 'algorithmic', the off-by-one error occurred. Thealgorithmiccalculation inpersian-datev1.1.0 seems unable to correctly calculate the start date of 1404 following the 1403 leap year.The issue was resolved by explicitly setting the leapYearMode to 'astronomical' during initialization. The astronomical calculation within persian-date v1.1.0 appears to handle the 1403/1404 transition correctly in this specific instance.
For users of persian-datepicker v1.2.0 (and its dependency persian-date v1.1.0) experiencing this off-by-one error for the year 1404 SH, the recommended solution is to explicitly configure the leapYearMode to 'astronomical' in the JavaScript initialization options.