I have tested this item ✅ successfully on 9769b06

I have successfully tested this! Merci @cyrez ;)

did you also test this with non-gregorian calendars such as jalali with the farsi language pack

did you also test this with non-gregorian calendars such as jalali with the farsi language pack

The code change should not affect non-gregorian calendars, as same issue, and same check for non-gregorian calendar for input event handler.
But i just tested with Farsi. Same issue before. After applying the patch, the issue is fixed as well (eg. you can pick a day in the calendar, set manually the time (for example, enter for the first 2 digits "۰۰") and on save, it keeps now the manual edit from the input.

Of course, another test with a non-gregorian calendar would be better ;-)

I have tested this item ✅ successfully on 9769b06

Manual time edits in the Jalali(farsi) calendar saves successfully with patch.

I have tested this item 🔴 unsuccessfully on 9769b06

Changing my test result to Unsuccessful.

I previously marked this as a successful test but I need to retract that. Due to my lack of familiarity with Farsi and the Jalali calendar numerals, I misinterpreted the output during my testing and incorrectly thought it had saved properly.

To be safe I am changing my vote to unsuccessful for now. I highly recommend that someone who better understand Farsi gives this a proper test.

Sorry for the confusion!

I have tested this item 🔴 unsuccessfully on 9769b06

Changing my test result to Unsuccessful.

I previously marked this as a successful test but I need to retract that. Due to my lack of familiarity with Farsi and the Jalali calendar numerals, I misinterpreted the output during my testing and incorrectly thought it had saved properly.

To be safe I am changing my vote to unsuccessful for now. I highly recommend that someone who better understand Farsi gives this a proper test.

Sorry for the confusion!

@krishnagandhicode If that means that you were not able to test, then please change to "Not tested". Unsuccessful should only be used if a human test fails for a PR or if the PR breaks something.

I have not tested this item.

@krishnagandhicode If that means that you were not able to test, then please change to "Not tested". Unsuccessful should only be used if a human test fails for a PR or if the PR breaks something.

Alright - but According to me this does not work for farsi/jalali calendar.

I have not tested this item.

@krishnagandhicode If that means that you were not able to test, then please change to "Not tested". Unsuccessful should only be used if a human test fails for a PR or if the PR breaks something.

Alright - but According to me this does not work for farsi/jalali calendar.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47626.

My test with Farsi (and the patch applied):

• Open calendar picker
• Select a day
• Manually changing the time in the input directly (not using time selector from calendar picker)
• Save.
• Result: the time edited manually as set in input is stored.

@krishnagandhicode could you explain what according to you, does not work with Farsi?
And did you test it as well with a gregorian calendar (English for example) to compare your result?
Thanks!

Note: the code change is not supposed to affect non-gregorian calendar, so i'm a bit surprized about the result of not working with a Farsi calendar.

@krishnagandhicode could you explain what according to you, does not work with Farsi? And did you test it as well with a gregorian calendar (English for example) to compare your result? Thanks!

Note: the code change is not supposed to affect non-gregorian calendar, so i'm a bit surprized about the result of not working with a Farsi calendar.

I completely agree on that and most probably it's something not okay on my side : (
( Well my test for gregorian calendar was a Successful test)

Okay I will give it another try.

I have tested this item ✅ successfully on 9769b06

RTC

I have tested this item 🔴 unsuccessfully on 9769b06

Final test before merge with JBT and installed fa-IR

• Before PR
  • With en-GB and Gregorian calendar
    • Seen problem in backend for all five date/time-picker Publishing, Featured and Created fields
    • Seen problem in frontend for the two Publishing fields
  • With fa-IR and Jalali (Solar Hijri) calendar
    • Seen problem in backend e.g. in Start Publishing field
      • ⚠️ Another error: if the time is changed in the hour and minute fields, it is saved in the other field instead -> created #47645
• Applied PR with Patch Tester and npm run build:js
  • ✅ With en-GB and Gregorian calendar
    • Backend for all five date/time-picker Publishing, Featured and Created fields are working now
      • Also working is only using date/time-picker or only entering date/time manually
      • Also working is clearing all fields, used is 'Start Punlishing' and 'Created Date' with current date/time
    • Frontend the two plublishing fields are working
      • Also working is only using date/time-picker or only entering date/time manually
  • ✅ With fa-IR and Jalali (Solar Hijri) calendar
    • Backend for all five date/time-picker Publishing, Featured and Created fields are working now
      • Also working is clearing all fields, used is 'Start Punlishing' and 'Created Date' with current date/time
      • The other error #47645 is still present
  • ❌ New error is found, changing hour and minute results in changing the year (e.g. from 2026 to 997)
    • This was not seen before PR and double checked in reverting the PR
    • see screen recording https://github.com/user-attachments/assets/fbdf1038-57be-4f07-a799-a70e42af47fb

Thank you @muhme for this advanced test!
I missed the data-alt-value attribute...
I will come up with an improved update tomorrow adding a date convertion for non-gregorian to populate correctly the data-alt-value.

@muhme @exlemor @brianteeman @richard67 @krishnagandhicode, after Heiko advanced test, an issue was found with datetime stored, not converted to Gregorian SQL format in Jahali calendar.

I've updated the PR to fix that, adding a correct conversion for date.

In the same time, Heiko reported a RTL issue for hour and minute selector #47645 which is not related to this PR, but as i was digging into the code, i've fixed it as well.
The issue is hour and minutes fields were swapped byt line 718 row.insertBefore(minutesCell, hoursCell); in RTL, but when getting the field values, the hour was getting minutes field and vice-versa for the minutes field getting the hour. To fix it, added additionnal check for RTL to reverse hour and minutes childnodes.

So that means this PR will need 3 test contexts:

• In gregorian LTR (primary test process of this PR)
• In RTL (gregorian or not) Note: as @brianteeman mentionned: "the hours:minutes should be displayed exactly the same in both LTR and RTL"
• In Jahali calendar (the date and time should be stored in DB in Gregorian format, but rendered in Jahali calendar in the datetime picker and input field)

I've done many test since yesterday since with this updated PR (LTR, RTL, Gregorian, Jahali) and it seems to fix the 2+1 issues reported).

Thank you for testing back this PR! 👍

Set back to Pending, as code is changed and new tests are required

Set back to Pending, as code is changed and new tests are required

Thanks @muhme 👍

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks Brian, but maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jahali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long tiem...), as the issue reported by @muhme is with Jahali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.
I'm surprised too after @muhme issue report #47645 about RTL issue with Jahali (which is not only for Jahali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes seems a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks Brian, but maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jahali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long tiem...), as the issue reported by @muhme is with Jahali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

I'm surprised too after @muhme issue report #47645 about RTL issue with Jahali (which is not only for Jahali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes seems a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks Brian, but maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jahali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long tiem...), as the issue reported by @muhme is with Jahali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

I'm surprised too after @muhme issue report #47645 about RTL issue with Jahali (which is not only for Jahali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes is a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks @brianteeman, maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jahali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long tiem...), as the issue reported by @muhme is with Jahali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

I'm surprised too after @muhme issue report #47645 about RTL issue with Jahali (which is not only for Jahali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes is a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks @brianteeman, maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jalali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long tiem...), as the issue reported by @muhme is with Jalali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

I'm surprised too after @muhme issue report #47645 about RTL issue with Jalali (which is not only for Jalali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes is a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

The test instructions are wrong. There is a difference between testing and RTL language such as Hebrew or Arabic and testing with Persian (farsi). Hebrew and Arabic both use the Gregorian calendar but Persian uses the very different jalali calendar. Please don't confuse the two.

Thanks @brianteeman, maybe my English is not perfect. I would be happy if you can help me to improve testing instruction.
I've mentionned "Jalali" for RTL with a eg. before (i think it means example in English, if not, i'm doing this error since a long time...), as the issue reported by @muhme is with Jalali calendar.
Of course, i can edit to improve the instruction to add mention of Gregorian calendar with RTL language.

I am surprised to hear that there is a problem with time on the jalali calendar as this was tested by native speakers. Unfortunately they are unable to retest at the moment as internet access is not currently available in their country.

I'm surprised too after @muhme issue report #47645 about RTL issue with Jalali (which is not only for Jalali, but for RTL languages) to not have been catched earlier, as mixing hours and minutes is a confusing behavior.

But with advanced and thorough testing of this PR, we could potentially fix all of this. ;-)

I've updated the testing instructions to prevent confusion.

I have tested this item ✅ successfully on 521376d

verified the bug in arabic and farsi
confirmed this pr fixes the bug in both arabic and farsi

I have tested this item ✅ successfully on 521376d

verified the bug in arabic and farsi
confirmed this pr fixes the bug in both arabic and farsi

Thanks a lot @cyrez for fixing the reported issues.

I was able to all the situations successfully - So this PR does what it says.

But unfortunately ;( there's a small issue I noticed that HAPPENS ONLY AFTER APPLYING THE PATCH.

while using Persian Language for Admin and selecting a date a date in date picker it also highlights it's adjacent date in calendar : see Screen Recording.

Thanks a lot @cyrez for fixing the reported issues.

I was able to test all the situations successfully - So this PR does what it says.

But unfortunately ;( there's a small issue I noticed that HAPPENS ONLY AFTER APPLYING THE PATCH.

while using Persian Language for Admin and selecting a date a date in date picker it also highlights it's adjacent date in calendar : see Screen Recording.

Thanks a lot @cyrez for fixing the reported issues.

I was able to test all the situations successfully - So this PR does what it says.

But unfortunately ;( there's a small issue I noticed that HAPPENS ONLY AFTER APPLYING THE PATCH.

while using Persian Language for Admin and selecting a date in date picker it also highlights it's adjacent date in calendar : see Screen Recording.

Thanks a lot @cyrez for fixing the reported issues.

I was able to test all the situations successfully - So this PR does what it says.

But unfortunately ;( there's a small issue I noticed that HAPPENS ONLY AFTER APPLYING THE PATCH.

while using Persian Language for Admin and selecting a date in date picker it also highlights it's adjacent date in calendar : see Screen Recording.
Recording.2026-04-27.221616.mp4

Hi @krishnagandhicode , i'm not able to reproduce your strange issue.
Could you turn on your browser javascript console to check if any script errors on the page?

Can someone else test with Persian language and check if same issue or not as the one reported in the video?

Yes, I can confirm @krishnagandhicode finding, using Chrome browser. See https://github.com/user-attachments/assets/9aa7e402-a9f7-4db9-928c-477606366583

• Selecting '۱۲' and selecting '۱۱' is working
• But selecting '۱۰' results in '۹' and selecting '۹' results in '۸'.

Yes, I can confirm @krishnagandhicode finding, using Chrome browser. See https://github.com/user-attachments/assets/9aa7e402-a9f7-4db9-928c-477606366583

• Selecting '۱۲' and selecting '۱۱' is working
• But selecting '۱۰' results in '۹' and selecting '۹' results in '۸'.

Before PR selecting one day is working and results in the selected day.

@mortezahonar can you take a look please

Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.
• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.
• In other words, any day can be selected, but selecting the first month is not possible.

No issues were observed when selecting subsequent months.

Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.
• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.

• In other words, any day can be selected, but selecting the first month is not possible.

No issues were observed when selecting subsequent months.

Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.

• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.

• In other words, any day can be selected, but selecting the first month is not possible.

No issues were observed when selecting subsequent months.

Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.

• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.

• In other words, any day can be selected, but selecting the first month is not possible.

This issue was not observed when the language was English.

No issues were observed when selecting subsequent months.

I hope my testing method is correct.

Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.

• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.

• In other words, any day can be selected, but selecting the first month is not possible.

This issue was not observed when the language was English.

No issues were observed when selecting subsequent months.

I hope my testing method is correct.

Joomla Version 5.4.4-dev installed

In English (Date & Time):

• Selecting hour and minute works correctly
• Typing hour and minute also applies to the calendar field
• This test was performed on all 5 date fields

Next step:
Persian language pack version 5.4.2v1 was installed and set as the backend language.

In the following path:
\media\system\js\fields

The contents of two files:

• calendar.js
• calendar.min.js

were replaced with the files from this PR.

All tests for 5 date/time fields were successful , which is greatly appreciated.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.

• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.

• In other words, any day can be selected, but selecting the first month is not possible.

This issue was not observed when the language was English.

No issues were observed when selecting subsequent months.

I hope my testing method is correct.

In the date field, when we type 01 for the month, after saving, 02 is displayed.

The only issue relates to going back to a date before the 11th day of the second month:

• When navigating backward with the mouse, it does not go beyond the 11th day of the second month.
• When navigating backward with the keyboard, you can reach any day of the first month, but upon saving, the second month is restored again.
• In other words, any day can be selected, but selecting the first month is not possible.

This issue was not observed when the language was English.

No issues were observed when selecting subsequent months.

Should I open a new issue for this?
Or does this issue belong within this PR?

Should I open a new issue for this? Or does this issue belong within this PR?

@mortezahonar IF you can reproduce the issue (you reported) WITHOUT applying the patch(code changes) from this PR - then YES Create a new issue.

With this patch:

It is not possible to select the first month using the mouse.

Using the keyboard (arrow keys) on the calendar, you can go back to the first month, but after selecting any day from the first month (the one we reached with the keyboard) and saving, it does not apply, and the second month will appear in the date field.

Without this patch:

You can select the first month and save successfully.

With this patch:

It is not possible to select the first month using the mouse.

Using the keyboard (arrow keys) on the calendar, you can go back to the first month, but after selecting any day from the first month (the one we reached with the keyboard) and saving, it does not apply, and the second month will appear in the date field.

Without this patch:

It is possible to select the first month and save it.

Thanks @mortezahonar for your testing, i was then able to reproduce and understand the issue @krishnagandhicode reported: related to change month.

There was a conflict with 'change' event handler on Jalali, and i changed it to 'blur'.

On my test in Persian, both issue of double select on first month reported by @krishnagandhicode (and confirmed by @muhme ) and issue to navigate in months reported by @mortezahonar seems to be fixed with the blur event.

On Gregorian calendar, works as before this last change.

So, this PR would need a reset of testing, and to test back in gregorian and non-gregorian, and as well with LTR and RTL languages.

Thank you @ALL for your detailed test and reports, helping to improve it! 👍

If we change the date to the first month and set one of the hour or minute fields, then check again whether the month has reverted to the second month; if it has changed to the second month, we change it back to the first month (after selecting the hour or minute) it is applied, and the first month is replaced with the selected day.

But if we try to change it again, the second month is selected by default.

In this case, even if we change to the first month, the second month is still saved unless we fill in the hour or minute and check whether it jumped to the second month; if it did, we revert it to the first month. This way, it is saved with the first month.

@mortezahonar, i've just updated the PR, and it seems to me that the issue with Jalali calendar is fixed.
If you could test the new updated PR? Thank you!!

Excellent. Tested with the mouse and it works correctly.

But the issue still persists with the keyboard. When entering the date with the keyboard in the calendar input, the same problem occurs.

For example, when typing (copy-paste):
1405-01-13 10:03:00
yyyy-mm-dd hh:mm:ss

Here, 13 represents the day, and 01 represents the first month.

After saving:
۱۴۰۵-۰۲-۱۲ ۱۰:۰۳:۰۰
is replaced, which is
1405-02-12 10:03:00

1405 (or ۱۴۰۵) represents the year, which we haven't touched.

In other words, when typing with the keyboard, the first month 01 is converted to 02, the second month.

But I reiterate, it works correctly with the mouse.

Excellent. Tested with the mouse and it works correctly.

But the issue still persists with the keyboard. When entering the date with the keyboard in the calendar input, the same problem occurs.

For example, when typing (copy-paste):
1405-01-13 10:03:00
yyyy-mm-dd hh:mm:ss

Here, 13 represents the day, and 01 represents the first month.

After saving:
۱۴۰۵-۰۲-۱۲ ۱۰:۰۳:۰۰
is replaced, which is
1405-02-12 10:03:00

1405 (or ۱۴۰۵) represents the year, which we haven't touched.

In other words, when typing with the keyboard, the first month 01 is converted to 02, the second month.

But I reiterate, it works correctly with the mouse.

@mortezahonar, thanks for your test.

You mean issue when copy/paste of a datetime, but if you enter the date in manual directly in input, do you have the same issue? (with no copy/paste)

What I mean is that this issue occurs when both of the following conditions happen together:

1. Exactly when we type the date directly and manually into the date input field using the keyboard, or copy-paste it.

2. But my emphasis is that the month in the date we type must be the first month (01) for this issue to be reproduced.

That is, in the format:
yyyy-mm-dd hh:mm:ss
only the month should be 01:
yyyy-01-dd hh:mm:ss

For example, you can use the example:
1405-01-13 10:03:00

In this example, the month is 01. You can either type it directly and manually, or copy-paste it, it makes no difference.

After saving, instead of:
yyyy-01-dd hh:mm:ss
it becomes:
yyyy-02-dd hh:mm:ss
Meaning the first month is converted to the second month. In Persian, 02 is written as ۰۲.

Previously, this same issue also existed with the mouse, which you kindly fixed.

Hello,

This PR is finally ready for testing again, with fixes for issues encountered with the Jalali calendar and some incidental improvements.

Fixes for Jalali date switch issue:

• Adding a strict parsing: while the user is still typing, the string is necessarily incomplete for most keystrokes. Without "strict", Date.parseFieldDate() silently falls back to "today" (a real Gregorian date), which would then be wrongly re-interpreted as a Jalali date below and converted into a nonsensical date (e.g. year ~2647). So we bail out until we have a genuinely complete, valid date, leaving data-alt-value untouched.
• Date.localCalToGregorian() (JalaliDate.jalaliToGregorian) expects a 1-indexed month, while date.getMonth() is 0-indexed (native JS). Symmetrically, its returned month is 1-indexed, while setMonth() expects 0-indexed. Forgetting either conversion causes an off-by-one day (or month) error.

Improvement made in this latest update to this PR:

• When the date picker is open, it now updates when the input field is manually modified.

Thank you all for testing again!

I have tested this item ✅ successfully on f43e8dd

I have tested this item ✅ successfully on f43e8dd

I have not tested this item.

I have not tested this item.

I have tested this item ✅ successfully on f43e8dd

I have tested this item ✅ successfully on f43e8dd

I have not tested this item.

I have not tested this item.

@mortezahonar I am confused. You submitt a successful test result, then you revert that by submitting „not tested“, then again a successful test result and then again „not tested“. What are you trying to do?

I apologize.

In the initial test, everything seemed to be correct.
So I marked the test as successful.

Later I realized that in
yyyy-mm-dd
when we set
yyyy-01-31
it converts to the date
yyyy-02-30. In other words, the first month jumps to the second month again.
For this reason, I reverted the test.

On the other hand, without this PR
in the Persian calendar, the positions of the hour and minute fields still get swapped, and the conversion problem from the first month to the second also exists.

I was concerned that perhaps there was no more room for improvement, so I discussed it with Cyril and reverted the test again.

The calendar has had some weaknesses for a long time, and I was worried that it might not be fixable.

I apologize again.

@richard67 yes, we are in discussion with @mortezahonar to do extended tests and improvements for this PR.
Quite many issues with Jalali, and it took me time to understand better the logic behind this calendar, and thanks to help from @mortezahonar i think we are closed to a working calendar picker in Jalali as well as improvements for Gregorian as well ;-)

@mortezahonar just updated the PR with a fix for the 31 to 30 of next month switch. To help me find out why this last issue (as others are fixed), i've asked help to Claude (well, i didn't use AI for such search before, but its help was useful to understand what was going wrong with Jalali, and was good to explain the intricacies of the Jalali calendar).

To fix it, it needs to create custom properties (named here rawYear, rawMonth, rawDay) for Date.parseFieldDate function and not use native JS getFullYear()/getMonth()/getDate() as they return only a gregorian value.

Now, it may be ok with YYYY-01-31 date.

Another issue i've found yesterday: with jalali calendar, when opening calendar picker and closing it without modifying the date nor time, on item save, the date was stored in Jalali format. Fixed as well.

So, open to new tests!

Thank you for your patience! (not easy to fix the Jalali calendar)

@richard67 yes, we are in discussion with @mortezahonar to do extended tests and improvements for this PR.
Quite many issues with Jalali, and it took me time to understand better the logic behind this calendar, and thanks to help from @mortezahonar i think we are closed to a working calendar picker in Jalali as well as improvements for Gregorian as well ;-)

@mortezahonar just updated the PR with a fix for the 31 to 30 of next month switch. To help me find out why this last issue (others reported are now fixed), i've asked help to Claude (well, i didn't use AI for such search before, but its help was useful to understand what was going wrong with Jalali, and was good to explain the intricacies of the Jalali calendar).

To fix it, it needs to create custom properties (named here rawYear, rawMonth, rawDay) for Date.parseFieldDate function and not use native JS getFullYear()/getMonth()/getDate() as they return only a gregorian value.

Now, it may be ok with YYYY-01-31 date.

Another issue i've found yesterday: with jalali calendar, when opening calendar picker and closing it without modifying the date nor time, on item save, the date was stored in Jalali format. Fixed as well.

So, open to new tests!

Thank you for your patience! (not easy to fix the Jalali calendar)

@richard67 yes, we are in discussion with @mortezahonar to do extended tests and improvements for this PR.
Quite many issues with Jalali, and it took me time to understand better the logic behind this calendar, and thanks to help from @mortezahonar i think we are closed to a working calendar picker in Jalali as well as improvements for Gregorian as well ;-)

@mortezahonar just updated the PR with a fix for the 31 to 30 of next month switch. To help me find out why this last issue (others reported are now fixed), i've asked help to Claude (well, i didn't use AI for such search before, but its help was useful to understand what was going wrong with Jalali, and it was good to explain the intricacies of the Jalali calendar).

To fix it, it needs to create custom properties (named here rawYear, rawMonth, rawDay) for Date.parseFieldDate function and not use native JS getFullYear()/getMonth()/getDate() as they return only a gregorian value.

Now, it may be ok with YYYY-01-31 date.

Another issue i've found yesterday: with jalali calendar, when opening calendar picker and closing it without modifying the date nor time, on item save, the date was stored in Jalali format. Fixed as well.

So, open to new tests!

Thank you for your patience! (not easy to fix the Jalali calendar)

@richard67 yes, we are in discussion with @mortezahonar to do extended tests and improvements for this PR.
Quite many issues with Jalali, and it took me time to understand better the logic behind this calendar, and thanks to help from @mortezahonar i think we are closed to a working calendar picker in Jalali as well as improvements for Gregorian as well ;-)

@mortezahonar just updated the PR with a fix for the 31 to 30 of next month switch. To help me find out why this last issue (others reported are now fixed), i've asked help to Claude (well, i didn't use AI for such search before, but its help was useful to understand what was going wrong with Jalali, and it was good to explain the intricacies of the Jalali calendar).

To fix it, i needed to create custom properties (named here rawYear, rawMonth, rawDay) for Date.parseFieldDate function and not use native JS getFullYear()/getMonth()/getDate() as they return only a gregorian value.

Now, it may be ok with YYYY-01-31 date.

Another issue i've found yesterday: with jalali calendar, when opening calendar picker and closing it without modifying the date nor time, on item save, the date was stored in Jalali format. Fixed as well.

So, open to new tests!

Thank you for your patience! (not easy to fix the Jalali calendar)

@richard67 yes, we are in discussion with @mortezahonar to do extended tests and improvements for this PR.
Quite many issues with Jalali, and it took me time to understand better the logic behind this calendar, and thanks to help from @mortezahonar i think we are closed to a working calendar picker in Jalali as well as improvements for Gregorian as well ;-)

@mortezahonar just updated the PR with a fix for the 31 to 30 of next month switch. To help me find out why this last issue (others reported are now fixed), i've asked help to Claude (well, i didn't use AI for such search before, but its help was useful to understand what was going wrong with Jalali, and it was good to explain the intricacies of the Jalali calendar).

To fix it, i needed to create custom properties (named here rawYear, rawMonth, rawDay) for Date.parseFieldDate function and not use native JS getFullYear()/getMonth()/getDate() as they return only a gregorian value.
This way, we receive in the calendar.js the correct date conversion from the Jalali date-helper.js

Now, it may be ok with YYYY-01-31 date.

Another issue i've found yesterday: with jalali calendar, when opening calendar picker and closing it without modifying the date nor time, on item save, the date was stored in Jalali format. Fixed as well.

So, open to new tests!

Thank you for your patience! (not easy to fix the Jalali calendar)

I have tested this item ✅ successfully on 8231029

The error of shifting by one day has been fixed.
The error of converting the first solar month to the second month has been fixed.
The error in manual date entry has been completely fixed.
The error when pressing the close button has been fixed.
The date in leap year has no problem and is correct.

The date for the entire year was checked both with the mouse and with manual keyboard entry.

Thanks to everyone and special thanks to @cyrez .

This is one of the most pleasant events.

I have tested this item ✅ successfully on 8231029

The error of shifting by one day has been fixed.
The error of converting the first solar month to the second month has been fixed.
The error in manual date entry has been completely fixed.
The error when pressing the close button has been fixed.
The date in leap year has no problem and is correct.

The date for the entire year was checked both with the mouse and with manual keyboard entry.

Thanks to everyone and special thanks to @cyrez .

This is one of the most pleasant events.

Also, an overflow error has been fixed.

For months in the Solar Hijri calendar that have more days than the equivalent months in the Gregorian calendar, the date used to jump by up to 3 days.
This issue has also been resolved.

I have tested this item ✅ successfully on 8231029

I tested this on Joomla 5.4.7 and it worked.

http://test2.b-li.org/images/2026-07-24105856.png
https://test2.b-li.org/مقالات/تست-تقویم-فارسی

I have tested this item ✅ successfully on 8231029

I tested this on Joomla 5.4.7 and it worked.

http://test2.b-li.org/images/2026-07-24105856.png
https://test2.b-li.org/مقالات/تست-تقویم-فارسی

RTC

RTC

I have tested this item 🔴 unsuccessfully on 8231029

I have tested this item 🔴 unsuccessfully on 8231029

I have tested this item 🔴 unsuccessfully

@skkh84 What exactly went wrong with the test?

@muhme
We are reviewing and reproducing it with @skkh84.

@muhme
We are reviewing and reproducing it with @skkh84.

@muhme We are reviewing and reproducing it with @skkh84.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47626.

Thanks for testing. There's important changes and improvements to make it full working with Jalali, so thanks to keep me informed of what issue is there, and how to reproduce it so that i could check it asap ;-)

@muhme We are reviewing and reproducing it with @skkh84.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47626.

Thanks for testing. There's important changes and improvements to make it full working with Jalali, so thanks to keep me informed of what issue is still there, and how to reproduce it so that i could check it asap ;-)

@muhme We are reviewing and reproducing it with @skkh84.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47626.

Thanks for testing. There's important changes and improvements to make it full working with Jalali, so thanks to keep me informed of what issue is still there, and how to reproduce it so that i could check it asap ;-)

Note: gregorian calendar test are required as well. To be sure Jalali fixes don't affect gregorian calendar picker. RTL/LTR to be check as well.

I have tested this item ✅ successfully on 8231029

I have tested this item ✅ successfully on 8231029

The test was performed for both Jalali and Gregorian dates.

No problems were observed.

The test was performed for both Jalali and Gregorian dates.

No problems were observed.

@mortezahonar Does that refer to @skkh84 's test, or you have tested together? Or did you make a separate test independently from him? If the latter: Please mark your test result in the issue tracker, then we have 2 successful human tests.

I first tested separately and it was successful, and I marked the test result as successful.

After @skkh84 's test, which was probably unsuccessful due to cache or something else,

we tested again together on his system, and the result was successful, which was marked accordingly.

Once more, I separately tested the calendar-type field for both the Gregorian and Jalali calendars, and I have attached the screenshot.

Thanks.

I have tested this item ✅ successfully on 723ba74

I have tested this item ✅ successfully on 723ba74

I have tested this item ✅ successfully on 723ba74

I have tested this item on 5.4-dev (npm ci && npm run build, Chrome), on the article Publishing tab (publish_up). All three linked issues are fixed. One small residual in the RTL time picker is noted below — it does not block the fix.

#46013 — manual edit not stored while picker open: with the picker open I typed 2026-03-15 10:30:00; data-alt-value updated, and after Save the DB #__content.publish_up held the manually typed value. Confirmed via onSubmit → setAltValue() that the gregorian alt-value is what actually gets submitted. ✅

#45933 — picker doesn't follow manual input: typing in the input with the picker open moved the day grid and the hour/minute selectors live to the typed date/time. ✅

Strict parsing: an incomplete value (2026-07) no longer corrupts data-alt-value to a "today" fallback — it keeps the last valid value while typing and becomes 0000-00-00 00:00:00 on blur if still invalid. ✅

#47645 — RTL hour/minute: forced dir=rtl. The time row is DOM-reordered in RTL ([title, minutes, hours, ampm]) and the fixed handlers now map correctly:

Hour edits no longer land in the minute field and vice-versa. ✅

Minor — RTL + 12-hour: the AM/PM selector still swaps hour⇄minute

The hour and minute change listeners get the RTL child-node swap, but the sibling AM/PM (.time-ampm) change listener (calendar.es5.js ~line 778, unchanged here) still reads childNodes[1]/[2], which are reversed by the same insertBefore(minutesCell, hoursCell). So in RTL + 12-hour mode, toggling AM/PM corrupts the time.

Reproduced: RTL, 12-hour field, 09:42 AM → switch to PM → 18:09:00 instead of 21:42:00 (hour/minute swapped). Hour/minute edits themselves are fine.

It's pre-existing and narrow (admin default is 24-hour, so it only affects a 12-hour format under an RTL language), but since this PR is exactly the RTL time-selector fix it's the natural place to finish it:

// AM/PM change handler — apply the same RTL swap as H/M
AP.addEventListener("change", function (event) {
    var c = event.target.parentNode.parentNode.childNodes;
    if (self.params.direction === 'rtl') {
        self.updateTime(c[2].childNodes[0].value, c[1].childNodes[0].value, c[3].childNodes[0].value);
    } else {
        self.updateTime(c[1].childNodes[0].value, c[2].childNodes[0].value, c[3].childNodes[0].value);
    }
}, false);

Minor — RTL + 12-hour: the AM/PM selector still swaps hour⇄minute

The hour and minute change listeners get the RTL child-node swap, but the sibling AM/PM (.time-ampm) change listener (calendar.es5.js ~line 778, unchanged here) still reads childNodes[1]/[2], which are reversed by the same insertBefore(minutesCell, hoursCell). So in RTL + 12-hour mode, toggling AM/PM corrupts the time.

Reproduced: RTL, 12-hour field, 09:42 AM → switch to PM → 18:09:00 instead of 21:42:00 (hour/minute swapped). Hour/minute edits themselves are fine.

It's pre-existing and narrow (admin default is 24-hour, so it only affects a 12-hour format under an RTL language), but since this PR is exactly the RTL time-selector fix it's the natural place to finish it:

// AM/PM change handler — apply the same RTL swap as H/M
AP.addEventListener("change", function (event) {
    var c = event.target.parentNode.parentNode.childNodes;
    if (self.params.direction === 'rtl') {
        self.updateTime(c[2].childNodes[0].value, c[1].childNodes[0].value, c[3].childNodes[0].value);
    } else {
        self.updateTime(c[1].childNodes[0].value, c[2].childNodes[0].value, c[3].childNodes[0].value);
    }
}, false);

@cyrez Could you check and if ok implement @tecpromotion 's suggestion? Thanks in advance.

@cyrez Could you check and if ok implement @tecpromotion 's suggestion? Thanks in advance.

Because we will start to prepare the upcoming releases in the next days, we might also merge this PR as it is and make a new issue for the remaining 12h format problem so that can be fixed with a follow up PR.

Thank you @StefanSTS for your advanced testing!

Minor — RTL + 12-hour: the AM/PM selector still swaps hour⇄minute

The hour and minute change listeners get the RTL child-node swap, but the sibling AM/PM (.time-ampm) change listener (calendar.es5.js ~line 778, unchanged here) still reads childNodes[1]/[2], which are reversed by the same insertBefore(minutesCell, hoursCell). So in RTL + 12-hour mode, toggling AM/PM corrupts the time.

Reproduced: RTL, 12-hour field, 09:42 AM → switch to PM → 18:09:00 instead of 21:42:00 (hour/minute swapped). Hour/minute edits themselves are fine.

It's pre-existing and narrow (admin default is 24-hour, so it only affects a 12-hour format under an RTL language), but since this PR is exactly the RTL time-selector fix it's the natural place to finish it:

// AM/PM change handler — apply the same RTL swap as H/M
AP.addEventListener("change", function (event) {
    var c = event.target.parentNode.parentNode.childNodes;
    if (self.params.direction === 'rtl') {
        self.updateTime(c[2].childNodes[0].value, c[1].childNodes[0].value, c[3].childNodes[0].value);
    } else {
        self.updateTime(c[1].childNodes[0].value, c[2].childNodes[0].value, c[3].childNodes[0].value);
    }
}, false);

Good catch with the AM/PM time format in RTL direction. 👍

I've added your fix (and tested it as well, confirm the issue before and the fix with the change).

Thank you all for your tests to help making the calendar picker more robust! (and Jalali ready).

Because we will start to prepare the upcoming releases in the next days, we might also merge this PR as it is and make a new issue for the remaining 12h format problem so that can be fixed with a follow up PR.

Just saw my email (vacation week), so thank you to inform me! This was a last minor quick fix thanks to @StefanSTS ;-)

@richard67 it seems i've got a copy/paste issue with tabulation...

@cyrez, your thanks above was probably meant for @tecpromotion, not for @StefanSTS. :-)

✅ Final test before merge with JBT and installed fa-IR

• Before PR
  • With en-GB and Gregorian calendar
    • Seen manual time change inputs in backend for all five date/time-picker Publishing, Featured and Created fields are overwritten with actual time on save
    • Seen this problem in frontend for the two Publishing fields
  • With fa-IR and Jalali (Solar Hijri) calendar
    • Seen manual time change is overwritten in backend e.g. in Start Publishing field
    • Seen if the time is selected in the hour and minute fields, it is saved in the opposite field instead
• Applied PR with gh pr checkout 47626 && npm run build:js
  • ✅ With en-GB and Gregorian calendar
    • Backend for all five date/time-picker Publishing, Featured and Created fields are working now
      • Also working is only using date/time-picker or only entering date/time manually
      • Also working is clearing all fields, used is 'Start Punlishing' and 'Created Date' with current date/time
    • Frontend the two plublishing and the thwo featured fields are working
      • Also working is only using date/time-picker or only entering date/time manually
  • ✅ With fa-IR and Jalali (Solar Hijri) calendar
    • Backend for all five date/time-picker Publishing, Featured and Created fields are working now
      • Also working is clearing all fields, used is 'Start Publishing' and 'Created Date' with current date/time
      • Picked minutes and hours are saved correctly
      • Selecting '۱۲', '۱۱', '۱۰' and '۹' is saved

Thank you very much @cyrez for your contribution. Thank you @brianteeman for support. Thank you @tecpromotion for support and testing. Thanks to @exlemor, @krishnagandhicode, @mortezahonar, @skkh84 and @sadjadii-sadjadii for testing.

@cyrez, your thanks above was probably meant for @tecpromotion, not for @StefanSTS. :-)

Oh yes, sorry i selected the wrong "Stefan"... Yes, of course, thank you to @tecpromotion 👍