[Aurora] - Formatted Date component

[sneridagh]

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 FormattedDate from 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 moment library with something maintained and lightweight.

Related: #94

Link to the parent PLIP

plone/volto#6638

[davisagli]

Let's use date-fns for parsing dates and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat for formatting them, instead of momentjs.

[stevepiercy]

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.

[davisagli]

@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.

[stevepiercy]

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. 🤔

[sneridagh]

@davisagli date-fns was 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.

[stevepiercy]

Interesting data points.

• https://github.com/orgs/date-fns/discussions/2521
• https://bundlephobia.com/package/date-fns@4.1.0

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.

[sneridagh]

@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.