Repository navigation
[Aurora] - Formatted Date component #68
Description
Activity
- added a parent issue
on Feb 7, 2025 Let's use
date-fnsfor parsing dates and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat for formatting them, instead of momentjs.Does this task have any dependency on plone/Products.CMFPlone#4115 ? I think that localization and formatting of dates in the backend is a prerequisite. I'm not sure.
@stevepiercy They're not tightly coupled. The backend isn't responsible for localization and formatting of dates, but it does need some changes to make sure that the publication and expiration dates in the REST API have a timezone specified, and that the Event content type has a field for which timezone it should be displayed in. Once that is done, the frontend component can use that information to display event dates in the intended timezone instead of always the viewer's local timezone, but it's not a blocker for working on other aspects of the frontend component.
I need to polish up that event PLIP for the Alpine Sprint and remove the draft status. Now that we have sub-issues, it should be more clear. I'll also find those two issues you mention and link to this one, and add this to the event PLIP as a sub-issue. Then should this sub-issue have those two issues as sub-issues? Maybe that's too much. 🤔
@davisagli
date-fnswas still pretty big in size, and not sure if maintained anymore, we need to investigate, but yeah, it's a good one to investigate about the most suitable and sustainable dates best practices. I'll add an issue.Interesting data points.
Can we restrict locales to reduce its size? It doesn't make sense to throw in locales or timezones that the client doesn't want or need like Moment.js does. If that's not possible, then I'd say let's do this in the backend. I think the docs answered my question.
https://date-fns.org/v4.1.0/docs/I18n
It might seem complicated to require and pass locales as options, but unlike Moment.js which bloats your build with all the locales by default date-fns forces developer to manually require locales when needed.
As far as maintenance, there was a recent 4.0 release that added timezone support, and plans for 5.0.
https://blog.date-fns.org/v40-with-time-zone-support/
Although I have to say, it took 4 versions to add timezone support? Shouldn't that have been a priority in v1? smh.
@stevepiercy the state of the art is very good using vanilla JS nowadays. There are still some painpoints, specially in parsing, where libraries are still meaninful. Matters as display/i10n/i18n are solved in modern browsers. So, we only need a good parser.
For Seven, let's keep in mind that we depend on
react-aria-componentsand therefore can easily use@internationalized/datewhich is a very good alternative to moment.js https://react-spectrum.adobe.com/internationalized/index.htmlReacted by Katja Süss2 remaining items
- changed the title
[-][Seven] - Formatted Date component[/-][+][Aurora] - Formatted Date component[/+]on Jun 2, 2026 - added a parent issue
on Jun 4, 2026 - removed a parent issue
on Jun 4, 2026 - added a parent issue
on Jun 4, 2026 While working on the History view (#30/#120) we ran into a locale problem that the
FormattedDateport should solve along the way: Aurora currently mixes two locale sources on the same screen.- UI strings follow the i18next app language (negotiated server-side).
- Dates and times formatted with react-aria's
useDateFormatterfollow the browser locale, because no react-ariaI18nProvideris mounted anywhere in the app.
Observable result: with a German browser and the app language set to English, the
@@contentsdate columns and the History view's date tooltips render German-formatted dates ("10.06.26, 14:46" / "Mittwoch, 10. Juni 2026 …") inside an English UI. In the History view the mix even occurs within a single table cell: the relative time ("44 minutes ago") uses the i18next language while its tooltip uses the browser locale.
Suggestion for the
FormattedDatework:- Mount react-aria's
I18nProviderat the app root, fed with the Aurora-managed locale, souseDateFormatter(and the new component) follow the app rather than the browser. - Define the policy once: which locale wins for date formatting — app UI language, content language, or browser?
- Align manual
Intl.*usages (e.g. the relative-time formatting in the History view, which is also a candidate to move into the shared component/helper) with the same source.
Related: #94 (moment replacement) —
Intl+I18nProvidermight cover most of whatmomentdid for formatting.
Metadata
Metadata
Assignees
Type
Projects
- Status
- Status
Important
If you are not a member of the Volto Team or Developers Team in the Plone GitHub organization, then do not work on or comment on this issue.
The
FormattedDatefrom Volto needs to be ported to TypeScript, transferred to@plone/components.Move also tests and Storybook there.
https://github.com/plone/volto/blob/main/packages/volto/src/components/theme/FormattedDate/FormattedDate.jsx
Investigate the complete replacement for
momentlibrary with something maintained and lightweight.Related: #94
Link to the parent PLIP
plone/volto#6638