Add multi timezone unit tests

[marob]

What does it do?

This PR adds running unit tests (related to dates) in multiple timezones to detect issues happening on non UTC timezones.

Why is it needed?

By running unit tests only on 1 TZ (UTC), issues like #1223 will happen and be difficult to reproduce and fix.

In #1241 (comment), we ended the discussion by noticing that multiple timezone unit test would be useful, but also that using mocks wouldn't work.
Since then I found multiple sources saying that modifying TZ at runtime won't work as expected (see https://www.appsloveworld.com/reactjs/100/2/how-do-i-set-a-timezone-in-my-jest-config for example).

The only solution is then to run multiple jest commands (in parallel) with different initial configurations/TZ.
This is what this PR is doing.

N.B: tests will fail as DatePicker doesn't work as expected on non UTC (positive) TZ. That's a proof that having multi timezone tests is useful to track issues on non UTC TZ.

How to test it?

Run yarn test in root.

You can also run only the multi TZ tests by running yarn test:timezone:all in packages/strapi-design-system directory, or event only for 1 TZ with, for example, yarn test:timezone:europe-paris.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
design-system	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 8, 2023 2:09pm
design-system-website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 8, 2023 2:09pm

[marob]

@joshuaellis I've managed to put in place the execution of unit tests on multiple timezones. What do you think?

[joshuaellis]

If i'm being honest, i'm not keen on the fact we need multiple commands to run tests against different timezones, it feels like something we'll easily miss... Adobe seem to be able to do this inline – https://github.com/adobe/react-spectrum/blob/8e6cefdb5f13aa61eab9fcf5c91f2eaac1d807b5/packages/%40internationalized/date/tests/conversion.test.js#L141 which is something i'd rather explore more to be honest.

[marob]

If i'm being honest, i'm not keen on the fact we need multiple commands to run tests against different timezones, it feels like something we'll easily miss... Adobe seem to be able to do this inline – https://github.com/adobe/react-spectrum/blob/8e6cefdb5f13aa61eab9fcf5c91f2eaac1d807b5/packages/%40internationalized/date/tests/conversion.test.js#L141 which is something i'd rather explore more to be honest.

I understand. I'd prefer being able to mock too.
But, it's not possible (or prove me wrong).

In your example, the mocking part is... useless.
The test is OK without the spy! Remove it and the test still passes.

Also, if you add some logs (console.log(getLocalTimeZone(), timeZone);) in getTimeZoneOffset code (and keep the spy), you'll see that getLocalTimeZone() always returns the first timezone (here 'America/New_York') even in the other loop iterations, which demonstrates once again that the spy is useless and doesn't work as expected.

Really, I don't think there's a better way than running jest several times with different configurations.

Finally, about your fear of "missing" the commands to run, in my MR the yarn test runs the tests as before plus the tests on Date/Time-related components in 2 other timezones. You don't have to think about it, it'll run automatically.

Worst problems are that it's not running in watch mode (but maybe we could add it?) and that we may skip testing a new component that is Date-related if its name doesn't match the Time|Date regex.
But all things considered, it's still better than not testing in multiple timezones at all in my opinion.

[marob]

@joshuaellis I see you already tried using spy here without success.