add date to disclosure page

[jsms90]

Product requirements:

• Show author the date based on their timezone

Designs:

Current:

Potential options:

• https://date-fns.org/
• https://github.com/iamkun/dayjs
• Pubsweet currently depends on Moment.js already

[jsms90]

We had a discussion at standup about the product requirements for this. Showing the date based on the user's timezone seems to be a best guess for now. But we're aware that the journal only shows GMT publication dates, so there was a questions around whether we would want to show a different date to the author within the wizard.

The suggestion here is to add a date library to the project & go with author's timezone for now, with the understanding that product requirements may change.

[jsms90]

Having had a brief look into date libraries this afternoon. Started with comparing Moment.js & date-fns:

• a decent summary of the problems with Moment.js that have lead to people using date-fns instead: Add a brief comparison with Moment.js? date-fns/date-fns#275 (comment)
• article on migrating from Moment.js to date-fns: http://jmduke.com/posts/migrating-from-moment-to-date-fns/
• a comparison article on sitepoint: https://www.sitepoint.com/date-fns-javascript-date-library/

Well, according to Sasha Koss, the creator of date-fns, Moment.js has a few inherent problems which motivated him to create date-fns. Sasha expands on what these problems are on the project’s GitHub page, but in a nutshell:

Moment.js is mutable which can cause bugs.

• It has a complex OOP API (which doubles the mutability problem).
• It has a performance overhead due to the complex API.
• Its build size is large when used with Webpack, as locale files are included as part of the bundle.

Let’s contrast that with date-fns (taken from the project’s homepage):

Date-fns is immutable, always returning a new date instead of changing the one you pass in.

• It has a simple API. You always have one function that does one thing.
• It is fast. You can be sure that your users will have the best user experience.
• It is the perfect companion for Webpack. With the function-per-file style you can pick just what you need and stop bloating your project with useless functionality.

One thing that stands out as a potential problem though is in the "time zones" section of that article:

Time zones

One disadvantage of date-fns is that it doesn’t currently have any time zone helper functions like Moment.js does.

May not actually be an issue - will need to look into this properly next week. But may depend on what our product requirements are in the end. Especially if we don't end up showing the author the date based on their own timezone, date-fns is looking pretty good.

[hdrury1]

Especially if we don't end up showing the author the date based on their own timezone, date-fns is looking pretty good.

Product requirements are that any user-facing feature displays date/time in user's zone.