CRM: Refactor IntlDateFormatter dependency

[kallehauge]

We used to rely on strftime before migrating to the monorepo (#28314), but PHPCompatibility.FunctionUse.RemovedFunctions.strftimeDeprecated revealed that it has been flagged as deprecated since PHP 8.1:

warning - Function strftime() is deprecated since PHP 8.1; Use date() or IntlDateFormatter::format() instead (PHPCompatibility.FunctionUse.RemovedFunctions.strftimeDeprecated)

We chose to refactor to use IntlDateFormatter in dc36c7a to satisfy PHPCS and be preventive in terms of strftime being removed but IntlDateFormatter requires the intl extension.
We might as well use date() and thereby keep same system requirements as before (which then also means that my local Jetpack Docker environment doesn't throw errors anymore 😄).

Proposed changes:

• Switched from IntlDateFormatter to date.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

• p1676069293714539-slack-C04J4UG3FLG

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

Scenario 1: Create new task/event

• Spin up site locally
  • (Make sure the intl extension is disabled if you want to reproduce the initial error before using this refactor)
• Go to /wp-admin/admin.php?page=zbs-add-edit&action=edit&zbstype=event
• Create a new task and set a start & end date (remember the dates to compare with)
  • The rest of the data on the task doesn't matter and could just be abcdefg.
• Verify that the date was created and make check that the dates and times still match

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Crm plugin:

• Next scheduled release: March 7, 2023.
• Scheduled code freeze: February 27, 2023.

[kallehauge]

The variable was overridden on line 769, so there's no need for us to keep it around.
As far as I can see, then it must have been used when together with an early bail out return so we'd show it as a default value but that never happens.

[coder-karen]

I know this is still a draft but I thought I'd see if I could replicate the issue and test the fix, however I couldn't replicate the issue.

[kallehauge]

I know this is still a draft but I thought I'd see if I could replicate the issue and test the fix, however I couldn't replicate the issue.

Thank you for taking the time @coder-karen - did you check if you have the intl extension with e.g. phpinfo() as well?

[coder-karen]

Ah no I didn't - it is enabled. I tried to spin up a JN site with an older (pre 7.2) version of PHP since it's apparently enabled by default on PHP versions above 7.2, but if the PHP version is lower CRM won't work at all.
It sounds like it may be an edge case then, where people / hosts have specifically disabled the intl extension? Still working on replicating though...

[kallehauge]

[...] it's apparently enabled by default on PHP versions above 7.2, but if the PHP version is lower CRM won't work at all.
It sounds like it may be an edge case then, where people / hosts have specifically disabled the intl extension?

I'm pretty sure it doesn't come as default and requires specific "opt-in" arguments to activate/install it (e.g.: I'm using the Jetpack Monorepo's Docker setup with PHP 7.4.25; read: newer than 7.2) and I get the error.

That being said, then intl is a very common PHP extension, but my intention with this PR is to prevent us introducing new PHP extensions during the migration if we don't have to (and in general) and this seems like a no-compromise alternative 😄
So as long as the PR works as expected, then I'm personally not too worried about replicating the issue on environments that doesn't have intl since we already know it's an issue 😛

[anomiex]

I think this long comment could use some rewriting. It comes across now as "instead of using date, we use date because date isn't affected by the locale issues like date is".