DateTimeWidget uses content language rather than current user's language for format

[JeffersonBledsoe]

Describe the bug

The DatetimeWidget currently passes the language of the current content to reactDates in order to set the display: https://github.com/plone/volto/blob/b629e5acbc2539f9ab1ef758fca4965eec9ffb44/packages/volto/src/components/manage/Widgets/DatetimeWidget.jsx#L296 https://github.com/plone/volto/blob/b629e5acbc2539f9ab1ef758fca4965eec9ffb44/packages/volto/src/components/manage/Widgets/DatetimeWidget.jsx#L209-L211

This potentially results in the wrong date being entered, especially when the timezone for a language code without a country code differs from one with a country code (e.g. en results in MM/DD/YYYY whilst en-GB or en-AU result in DD/MM/YYYY).

We should be using the currently logged in user has set in their personal preferences (i.e. the language set by react-intl)

Steps to reproduce

1. Set your user preference language to 'English (United Kingdom)`
2. Create a page with the language set to 'English'
3. Set the publishing date (or any other date field) to be 02/03/2024

 Expected result

The date shows as 2nd March 2024

 Actual result

The date shows as 3rd February 2024

[JeffersonBledsoe]

Doing some more testing, this seems to be a little inconsistent, so I think the issue might be coming from somewhere else in the handling of languages between content and the CMS UI. Feel free to close this for now or leave open until some more testing has been done :)

[stevepiercy]

@JeffersonBledsoe can you reproduce the lack of localization in Plone Classic UI? If you see it there, then can you see if there is an issue already in https://github.com/plone/Products.CMFPlone/issues

I think I see it there as well, although the publishing date indicators are clearly marked as mm/dd/yyyy to remove some ambiguity. I also made sure to toggle my user preferences for timezone and language between US and UK when creating each page. I would expect that a user's language settings to store a locale and use it to display data correctly.

Somewhat related, we have not yet addressed localization of date formats in the plone.app.event PLIP, and it should go into the proposed PLIP and its Design document. The only mention of publish and expiration dates is this one item:

• [ ] Ensure that Publish and Expiration Dates have times.

[stevepiercy]

Also I think that publication date is effective, whereas expires is obvious, in the content types for Plone REST API. https://6.docs.plone.org/plone.restapi/docs/source/endpoints/content-types.html#plone-document. Ah, yes, this docs page confirms it as such: https://6.docs.plone.org/plone.restapi/docs/source/usage/i18n.html

        "effective": {
            "behavior": "plone.dublincore",
            "description": "Si la fecha es del futuro, el contenido no se mostrar\u00e1 en los listados y las b\u00fasquedas hasta esa fecha.",
            "factory": "Date/Time",
            "title": "Fecha de Publicaci\u00f3n",
            "type": "string",
            "widget": "datetime"
        },

[stevepiercy]

I found this PR mentioned in the PLIP https://github.com/plone/plone.restapi/pull/1192. It is excluded as being outside the scope of the PLIP. I think this issue is a duplicate of that PR.

[JeffersonBledsoe]

@stevepiercy I'll check in Classic to see what the story is there. I did see those other issues (we ran into them ourselves a couple of weeks ago), but this issue is more to do with the rendering of the datetime input and the format it's using for that than the actual value displayed

[davisagli]

There may be some overlap between this issue and #6047. I think it makes sense to use the user's personal preference for this rather than the content language, but I haven't dug into what's missing to make that happen.

[JeffersonBledsoe]

Plone Classic uses <input type="datetime-local"> for the text input. This results in it ignoring both the content language and the Personal Preferences language. It uses the system language. While the personal preferences is probably the best option (especially if we further improve this to default to the user's system language if they haven't explicitly set their language), using the system language is still a better option for the user than using the content language, especially in multi-lingual sites where associated datetime formates might change depending on the language of the content.