🐛(react) fix the DatePicker timezone management

[lebaudantoine]

Purpose

Fix the component's timezone management.

Proposal

DatePicker and DateRangePicker now support only string as inputs.
They always return an ISO 8601 in UTC as output.

Allowed inputs formats :

• ISO 8601 date string and time string, with time components and a UTC offset.
• ISO 8601 date and time string, with time components in UTC time.

Plus, this introduces a new utils function convertDateValueToString. Its responsibilities are :

• Ensure that any output value is converted back to an ISO 8601 date and time string with in UTC.
• Harmonize the way we output values.

By introducing this utility function, the proposal aims to ensure consistent and standardized output values across different scenarios.

Finally, a timezone prop has been added to set the timezone of the component. By default, the component's timezone is set to the user locale one. Please read component's documentation, it has been updated with all these recent changes.

[changeset-bot]

🦋 Changeset detected

Latest commit: 371c2ad

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@openfun/cunningham-react	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[AntoLC]

A few things, except than that seems good.

[NathanVss]

I'm wondering what motivated this change ?

IMO we could think of a way to streamline more simply the date format management:

• The value props could be Date | undefined
• The onChange callback attrbitute could be Date | undefined

From my perspective we should avoid manipulating dates without the TZ, it lets the door opened to lots of TZ related bugs. A date without the TZ has no meaning, so in my opinion it could be considered as a bad practice.

This could led to potential problems when dealing with world-wide users, for instance 01/01/2023 00:00:00 has a different meaning in each 1000km separated territories accros the earth, so there is a door opened to subjective interpretation as it lacks informations. While 01/01/2023 00:00:00 Z as the same meaning anywhere on earth ( Z = UTC ), no subjective interpretation is possible and we will never face a situation where the calendar shows the same date in the US and in Mumbai .. which is a non sense: it should show different dates relative to their TZ.

A calendar with the value 01/01/2023 00:00:00 Z should display:
31/12/2022 in the US
01/01/2023 in Europe
01/01/2023 in Asia

I faced lots of this issues when working for a world-wide platform with users from San Fransisco to Shanghai and that's one of my main return on experience. 😅

Just to avoid any misconception: I'm just saying that this could led to mis-usages which we should maybe hard-prevent.

( WDYT @jbpenrath @AntoLC ) ?

[lebaudantoine]

@NathanVss

I acknowledge the potential shortcomings in component’s timezone management. I understand and share your perspective. Here are few responses:

---

IMO we could think of a way to streamline more simply the date format management […]

I agree that having a single type of input, whether it's a string or a Date, would be an improvement.

I like your suggestion. The JavaScript Date object doesn't inherently store timezone information. It represents a moment in time without built-in capabilities for managing timezones. I'll take some time to consider your suggestion.

With react-aria, the ZonedDateTime type doesn't have a built-in constructor from a JS Date object. Therefore, internal conversion to a string is still required. However, ZonedDateTime does offer a toDate() method, which can be used to obtain a JavaScript Date object.

---

I'm wondering what motivated this change ?

The current date picker lacks the granularity to select a specific time, making it feel arbitrary to restrict the selection to only a date with a fixed and default time. This approach of forcing a time at midnight can result in different dates across timezones, which appears odd for a date picker designed primarily for selecting a day rather than a specific time.

I intended to leverage the various DateValue types provided by react-aria, including CalendarDate, CalendarDateTime, and ZonedDateTime.

---

This could led to potential problems when dealing with world-wide users […]

Developers can still pass an ISO 8601 string with a UTC offset to ensure proper conversion of the date to the user's local timezone. However, one area that could be improved is the situation where the date is cleared, resulting in the loss of time and timezone information. However, agreed, relying solely on the developer for this responsibility may not offer the most optimal developer experience.

---

I'm just saying that this could led to mis-usages which we should maybe hard-prevent.

Acknowledging that my proposal may introduce additional complexity, it is important to note that it also provides a significant advantage in terms of freedom and flexibility. Considering this, would you like me to reconsider the component design, incorporating your suggested default behavior? Your suggestion might simplify developer experience while using the component.

[lebaudantoine]

(This PR is the result of the discussion we had before our mutual holidays @jbpenrath about setting component selected date time to noon instead of midnight.)

[jbpenrath]

Nice job ! 👏