Apply User-Defined Date Formatting Settings to WP Admin React Components

[mgascam]

Fixes #6567

This pull request includes changes to ensure that user-defined date and time formatting settings are respected across various React components in the WooCommerce Payments plugin. The most important changes include the replacement of dateI18n with custom date formatting functions, the addition of a new DateFormatNotice component, and updates to test files to accommodate these changes.

Improvements to date and time formatting:

• client/capital/index.tsx: Replaced dateI18n with formatDateTimeFromString for date formatting in loan status and rows data. Added DateFormatNotice component to display a notice about date format changes. [1] [2] [3] [4] [5]
• client/components/account-status/account-fees/expiration-description.js: Replaced dateI18n with formatDateTimeFromString for expiration date formatting. [1] [2]
• client/components/active-loan-summary/index.tsx: Replaced dateI18n with formatDateTimeFromTimestamp for various date fields in the active loan summary. [1] [2] [3]
• client/components/disputed-order-notice/index.js: Replaced dateI18n with formatDateTimeFromString for dispute notice dates and ensured consistent timezone-independent comparison using UTC. [1] [2]

Addition of DateFormatNotice component:

• client/components/date-format-notice/index.tsx: Added a new component to display a notice about the date and time formats matching user preferences.
• client/components/date-format-notice/style.scss: Added styles for the DateFormatNotice component.

Test updates:

• Updated test files to mock date formats and include the new DateFormatNotice component in snapshots. [1] [2] [3] [4] [5] [6] [7] [8] [9]

Testing instructions

General Date and Time Display Testing

• Navigate to WP Admin > Settings > General and set your preferred Date and Time Formats and Timezone.
• Verify that the date format matches the user-defined settings in WordPress when you navigate to the WooPayments plugin pages.
• Verify that the dates and times are correctly converted from UTC to your preferred timezone.

Component Specific Testing

Transactions

• Navigate to WP Admin > Payments > Transactions.
• Verify the values in Date / Time and Deposit Date columns.

Capital Loans

This section is hidden if your user does not have capital loans. Follow the steps in this guide to create one offer for your user. Once the offer is created, your user will get an email to confirm it. Visit the link in the email, but make sure to use your local store URL, not the server one.

• Navigate to WP Admin > Payments > Capital loans
• Verify that the Active loan overview dates are formatted according to the user settings.
• Verify that the All Loans table dates are formatted according to the user settings. There are two columns that contain dates: Disbursed and First Paydown.

Deposits

• Navigate to WP Admin > Payments > Deposits
• Verify that the dates in the Deposit history table are formatted according to the user settings

• Click on a row and verify that the date and times in the Date /Time column of the deposit details are formatted correctly.

Disputes
You can use test cards to create disputed orders.

• Navigate to WP Admin > Payments > Disputes
• Verify the date and time in the Disputed on column (you may need to reveal it)

- Click one row to navigate to the details view and verify the dates

• Click on Challenge Dispute and verify the dates in the form are correct

Documents

In the server, you can use the cli to add a document to your account wp wcpay add_document_for_account 236870460 vat_invoice --period_from="2024-10-01 00:00:00" --period_to="2024-10-31 23:59:59"

• Navigate to WP Admin > Payments > Documents
• Verify that the dates in the Date and Description columns in the Documents list are correctly formatted

Date and time format change notice

• Navigate to any page under the WP Admin > Payments menu i.e. Transactions.
• Check that the following notice is displayed.

- Click the `settings link` and check that you are redirected to the `Settings > General` page. - Navigate back to the previous page. - Check that the notice is no longer displayed. - Delete the `wcpay_date_format_notice_dismissed` option. - Check the notice is displayed on any page under `WP Admin > Payments` menu. - Dismiss the notice by clicking on the icon. - Check that the notice is no longer displayed.

---

• Run npm run changelog to add a changelog file, choose patch to leave it empty if the change is not significant. You can add multiple changelog files in one PR by running this command a few times.
• Covered with tests (or have a good reason not to test in description ☝️)
• Tested on mobile (or does not apply)

Post merge

• Link to testing instructions from release testing doc following these instructions : Add link here / 'QA Testing Not Applicable'
• Add or update critical flows and testing instructions for critical flows, if applicable.
• Add what's changed (description, screenshot, demo videos etc.) to the release announcement post, if applicable.

[mgascam]

Added blocked status until we implement the inline notification in the TableCard header: woocommerce/woocommerce#53496. Please check previous comments for context.

[haszari]

client/components/date-format-notice/index.tsx: Added a new DateFormatNotice component to inform users about the new date and time formatting settings and provide a link to configure these settings.

Added blocked status until we implement the inline notification in the TableCard header: woocommerce/woocommerce#53496. Please check previous #9635 (comment) for context.

This is an important PR – making dates respect user preferences. Here's my understanding of why it's blocked:

• We're changing the date formatting.
• So we want to tell the merchant that things changed.
• The mechanism / UX we want to use for that notice is not implemented and needs a change in WooCommerce core.

This is unfortunate – we should be able to fix date formatting without implementing a new kind of notice.

Here are some options I think are reasonable:

1. Ship the change with a release note and clarify in docs (and any release comms). I.e. quietly change it.
2. Ship the change with a release note, clarify in docs etc as above AND implement some kind of notice in the admin UI. Any kind of notice, whatever works best / we can ship without a hassle.

@rogermattic @mgascam would you be concerned if we went with (1) approach – ship quietly? Do we expect significant support requests – @AashikP keen for your thoughts on risk of shipping quietly.

@rogermattic – how important is it to you that we delay shipping the date fix until we have a new kind of notice implemented in core?

After considering the importance of this announcement and how noticeable it should be, I decided to use an inline notice. It’s important enough to stand out but doesn’t need the prominence of something like a spotlight, which might be too distracting.

Personally, I think a spotlight notice is reasonable. It's a little loud, but this is a pervasive change (respecting date format throughout WooPayments), so a "global" notice is a good fit. We used a spotlight for payouts which was a less impactful and more localised change.

[rogermattic]

Here are some options I think are reasonable:

1. Ship the change with a release note and clarify in docs (and any release comms). I.e. quietly change it.
2. Ship the change with a release note, clarify in docs etc as above AND implement some kind of notice in the admin UI. Any kind of notice, whatever works best / we can ship without a hassle.

@rogermattic @mgascam would you be concerned if we went with (1) approach – ship quietly? Do we expect significant support requests – @AashikP keen for your thoughts on risk of shipping quietly.

I’d definitely go for option 2. I think it could get confusing for users if they see a change and don’t know how to get back to their previous setup.

1. They might not realise how their preferences are currently set up.
2. They could worry about exporting, especially if they have something configured elsewhere that depends on the date column.

So yeah, I think it’s quite important to show some kind of context or information.

@rogermattic – how important is it to you that we delay shipping the date fix until we have a new kind of notice implemented in core?

At first, I thought we already had that inline notice ready, so I definitely didn’t mean to delay shipping. I only suggested it because I thought it’d be helpful to have the notice closer to the context —that’s all. Sorry for complicating @mgascam ’s life in the process!

This is an important PR – making dates respect user preferences.

@mgascam apologies, but would it still be possible to somehow go back to the notice style and positioning that you had implemented initially, just with the copy I proposed?

[AashikP]

@AashikP keen for your thoughts on risk of shipping quietly.

From what I understand, this is a very welcome change that implements consistency across WooPayments. Is there a specific reason we'd want to ship this quietly?

Unless we do, there should be some (any) form of notice to the merchants. Without that, we can expect some support requests. Maybe it is because of confusion and, in some cases, anger because they never noticed that the time now reflects the time they've configured under General settings.

One extreme example is when the merchant blames us for the lost dispute. They might say they missed the deadline because they assumed the time was in UTC, their time zone, etc.

@aheckler We should also add a notice in the public docs letting them know what timezone WooPayments uses and how they can change it.

cc @francoishvz

[aheckler]

IMHO we should just ship this and not worry about it. No announcement needed other than the release notes / changelog.

The fact that the dates and times shown by WooPayments did NOT respect the merchant's core WP settings from the very beginning is/was a bug. This PR fixes that bug. And we release bug fixes all the time with zero notice. I don't think this one needs to be any different.

I wouldn't even bother mentioning this in the docs to be honest, since following the core WP settings is the obviously correct thing to do.

[AashikP]

The fact that the dates and times shown by WooPayments did NOT respect the merchant's core WP settings from the very beginning is/was a bug.

@aheckler Now that you mention it, you're right! I totally missed that this was originally reported as a bug. I assumed this to be a feature update.

There's only one merchant report in the bug report, and we will get back to them during the release phase.

We don't usually provide notices for bug fixes. That said, I'd still consider this notice as nice to have just to avoid confusion.

The public docs update is understandable since this was a bug to begin with. We don't need to specifically mention this in the docs.

[mgascam]

Thank you, everyone, for your helpful comments!

Ship the change with a release note, clarify in docs etc as above AND implement some kind of notice in the admin UI. Any kind of notice, whatever works best / we can ship without a hassle.

@haszari I also prefer this option, and it seems we are all aligned on it. I've made the necessary changes to use the BannerNotice component in this commit.

For context, I completely agree that this is a bug. However, my main concern has been avoiding unintended negative impacts from fixing it, especially given the low number of complaints. The suggestion to show a notice for merchants resonated with me as a practical solution. Additionally, I appreciated @rogermattic's idea to place the notice within the table context, as it would have been more targeted.

Initially, I assumed it would be straightforward to implement this change using the new TableCard component from the woocommerce/components repository. However, after gaining more experience, I realized I underestimated the complexity. Specifically, the plugin relies on the woocommerce/components bundle from WooCommerce core, which means we would need to wait for a new WooCommerce core release. This approach would be problematic, as merchants who update WooPayments without updating WooCommerce core would not see the notice.

Given this limitation, I believe moving forward with the BannerNotice is the best option. While not ideal, it ensures we can inform merchants about the change effectively.

I've added the notice to all pages under the Payments navigation menu. Below are some screenshots for your review—please let me know your thoughts.

Lastly, I’ll be on extended AFK starting Dec 23rd, so it would be great to get additional reviews and feedback next week. Thank you!

cc: @AashikP @aheckler

[AashikP]

Looks good to me! Thank you!

[Jinksi]

I’ve conducted a round of testing on this PR and can see that it is looking good! It is so good to see more consistent datetime handling across the UI and in the code. 🙌

I've left a suggestion about using WP option rather than localStorage to persist the banner dismissal state, which should improve UX for merchants who dismiss the notice.

To summarise the only inconsistencies that I’ve found (not blocking merge):

• Server-generated CSVs datetimes do not use the WP settings datetime format
• Client-generated CSV datetimes do use the WP settings datetime format, except for Transactions
  • Transaction client-generated CSV export looks to be intentionally matching the server formatting instead
  • We shouldn’t worry about inconsistencies across JS/server CSVs in this PR, since we are fixing those in Reporting: Move all CSV exports to endpoint (server) exports #9969. @Automattic/helix we should consider a consistent, intentional approach to datetime formatting as part of the Simplify CSV project paJDYF-g1S-p2 – either use the WP Settings datetime formatting, or use a standard format, e.g. ISO 8601.
• The main dates and times of the transaction timeline view don’t use the WP settings datetime format – this may need to be fixed upstream in @woocommerce/components
• Server-generated VAT invoices use a server-defined format – again, not a worry for this PR

Steps tested

• Set WP date/time settings to m_d_Y H_i (12_17_2024 23_56)
• Set WP store TZ to New York
• Set browser time to Mumbai (Browser Dev Tools → More Tools → Sensors)
• Payments → Overview
  • New notice displayed and links to the correct page ✅
  • Dismissing the notice works ✅
  • Payout dates are formatted as per WP settings ✅
• Payout detail view
  • Dates and times formatted as per WP settings ✅
• Payouts list view
  • Dates and times formatted as per WP settings ✅
  • Client-side CSV export dates and times are formatted as per WP settings ✅
  • Server CSV export dates and times are not formatted as per WP settings ⚠️
• Transaction detail view
  • Transation summary and dispute dates and times formatted as per WP settings ✅
  • Timeline event details (e.g. payout event) dates and times are formatted as per WP settings ✅
  • Main timeline dates and times are not formatted as per WP settings ⚠️
• Transactions list view
  • Dates and times formatted as per WP settings ✅
  • Client-side CSV export dates and times are not formatted as per WP settings ⚠️
  • Server CSV export dates and times are not formatted as per WP settings ⚠️
• Disputes list view
  • Dates and times formatted as per WP settings ✅
  • Client-side CSV export dates and times are formatted as per WP settings ✅
  • Server CSV export dates and times are not formatted as per WP settings ⚠️
• Dispute challenge view
  • Dates and times formatted as per WP settings ✅
• Capital Loan list view
  • Dates and times formatted as per WP settings ✅
• Documents list view
  • Dates and times formatted as per WP settings ✅
• VAT invoice download
  • Dates and times are formatted as per WP settings ⚠️ (server-generated)