#39218 - Custom Date Format Not Respected

[its-leofisher]

Description (*)

Locale settings in Date.php:82, Magento\Ui\Component\Form\Element\DataType\Date->prepare() is overriding incoming components $config dateFormat entry.

Logs below display how custom component dateFormat xml config gets overridden in prepare() function via Locale settings. First entry is with en_US and 2nd log is with de_DE validating issue despite locale.

[2024-10-10T08:26:26.221850+00:00] main.INFO: PREPARE JS Config: {"extends":"hidden"} [] []

[2024-10-10T08:26:26.222765+00:00] main.INFO: PREPARE Component Config: {"dataScope":"date_from","component":"Magento_Ui\/js\/form\/element\/date","template":"ui\/form\/field","formElement":"date","label":"Date From","dataType":"date","validation":{"required-entry":true,"validate-date":"YYYY-MM-DD"},"notice":"Enter the starting date to test the widget","options":{"showsTime":false,"dateFormat":"yyyy-MM-dd","inputDateFormat":"yyyy-MM-dd","outputDateFormat":"yyyy-MM-dd","pickerDateTimeFormat":"yyyy-MM-dd","pickerDateFormat":"yyyy-MM-dd","storeLocale":"en_US"},"storeTimeZone":"America\/New_York"} [] []

===============================

[2024-10-11T00:33:59.318103+00:00] main.INFO: PREPARE Component Config: {"dataScope":"date_from","component":"Magento_Ui\/js\/form\/element\/date","template":"ui\/form\/field","formElement":"date","label":"Date From","dataType":"date","validation":{"required-entry":true,"validate-date":"yyyy-MM-dd"},"notice":"Enter the starting date to test the widget","options":{"showsTime":false,"dateFormat":"dd.MM.yy","inputDateFormat":"yyyy-MM-dd","outputDateFormat":"yyyy-MM-dd","pickerDateTimeFormat":"yyyy-MM-dd","pickerDateFormat":"yyyy-MM-dd","storeLocale":"de_DE"},"storeTimeZone":"Europe\/Luxembourg"} [] []

The dateFormat config option was not in the original steps to reproduce XML but it is the primary option used for Validation and Frontend Display via Calendar Widget and DatePicker js files, when adding dateFormat to Ui component form xml issue still occurred.

Screenshot of issue prior to applied fix:

This fix adds null coalesce check if the components config option already has a set dateFormat if so then do not apply system locale dateFormat for incoming component else use $this->localeDate->getDateFormat();

Additional notes:

• Developer must provide validate-date format to ensure proper usage.
• Developer should provide an option in their plugin config to allow Store User to enable an override to use System dateFormat to apply instead of plugin specific format.

Related Pull Requests

This one

Fixed Issues (if relevant)

1. Fixes Date format not respected in date ui component #39218

Manual testing scenarios (*)

1. Tested against i39218 module

2. Also tested against my own module, added Save component to store into database confirming entire process works as intended:

• Installed plugin ItsLeoFisher_custom_test_module.zip
• Visit Content > Calendar Debug > Select A Date.
  • Observe format should be yyyy-MM-dd as set in view/adminhtml/ui_component/calendar_debug_form.xml instead of mm/dd/yyyy as default for en_US.
• Change My Account admin locale to German (Germany)
• Ran: bin/magento setup:static-content:deploy -f de_DE && bin/magento cache:clean
• Selected date from plugin page, date format was yyyy-MM-dd instead of mm.dd.yyyy, notice the periods in-between date groups which is default for Germany de_DE.

Output after applied fix:

[2024-10-11T00:41:59.077201+00:00] main.INFO: PREPARE Component Config: {"dataScope":"date_from","component":"Magento_Ui\/js\/form\/element\/date","template":"ui\/form\/field","formElement":"date","label":"Date From","dataType":"date","validation":{"required-entry":true,"validate-date":"yyyy-MM-dd"},"notice":"Enter the starting date to test the widget","options":{"showsTime":false,"dateFormat":"yyyy-MM-dd","inputDateFormat":"yyyy-MM-dd","outputDateFormat":"yyyy-MM-dd","pickerDateTimeFormat":"yyyy-MM-dd","pickerDateFormat":"yyyy-MM-dd","storeLocale":"en_US"},"storeTimeZone":"Europe\/Luxembourg"} [] []

Also, tested against other Locale settings via My Account > Account Setting (admin) and works as expected.

Questions or comments

I was also noodling over if Magento Core should add another XML config option to the date component to display an Override Checkbox, so that the burden is off the developer to develop this configuration and allows flexibility to the end User to use the Magento locale dateFormat instead of the modules explicitly defined dateFormat.

Screenshot example:

Possible changes needed for new config proposal:

• Setting a new option within definition.map.xml: <item name="useSiteLocale" type="boolean" xsi:type="xpath">settings/useSiteLocale</item> set to false, as this can be enabled by the developer.
• Add checkbox code to date.html with a KO binding to hide/display the checkbox
• Add observable in the date.js when checkbox is interacted with

If this is something worth while or should be Cores responsibility, I can create a ticket. I wanted to bring this up in Slack but was not able to join. If an invite can be sent to [email protected] I can bring it up in the channel.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• [] All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @its-leofisher. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[its-leofisher]

@magento run all tests

[its-leofisher]

Only Unit Tests failure is directly related to this PR. Since the incoming $config['options']['dateFormat'] is set prior to prepare() being called, the dateFormat will not be overridden by $this->localeDate->getDateFormat(); due to the updated code eventually negating the assertEquals of \Magento\Ui\Test\Unit\Component\Form\Element\DataType\DateTest::testPrepareWithoutTimeOffset:96

https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39285/9b9db73713b0403b152ce562a46a9180/Unit/console-error-logs.html

In this scenario if dateFormat is being explicitly set why should the localeDateFormat take priority? Should the test be updated to not equals?