Bug: Date display is inconsistent

[chenilim]

Steps to reproduce the behavior:

1. Add a date property to a card and set it
2. Note the display in the Card view (MM/DD/YYYY, e.g. 07/28/2021)
3. Close the card open a Board view
4. Add the date property to the Properties menu, to display in the card preview
5. Note the display in the card preview (MMMM DD, YYYY, e.g. Jul 28, 2021)

Expected behavior:
The date display should be consistent between the Card view and Card preview, which should be as follows:
If its the current year: February 25

If its not the current year: February 25, 2020

Screenshots:
Date in card view:

Date in card preview:

Platform:

• Focalboard v0.8.0 plugin
• Chrome 91 on macOS 11.4

Additional context:
Also, the date display on the Card view follows the Date format user setting, but the Card preview does not.

Recommended change:

• Extend the user date format setting to also include:
  • MMMM DD, YYYY, e.g. July 28, 2021 (make this the default)
  • DD MMMM, YYYY, e.g. 28 July, 2021
• Apply this user setting on all date property displays, including the Card view, card preview, tables, etc.

[chenilim]

@asaadmahmood, not a high priority, but assigning this to you for UX review. the main thing is to consider what our default date format should be (I propose MMM DD, YYYY because it's unambiguous), and what our supported date formats should be. Other Mattermost components (including Playbooks and Admin Console, etc.) have dates too, and we should (P3) ideally drive some general consensus.

[asaadmahmood]

@chenilim We have a similar date format for Playbooks and the Messages (in the center channel etc), which is Month Day Year (if its not the current year). I've updated the Expected Behaviour to include that.

[chenilim]

Thanks @asaadmahmood! I've updated the recommended change to use the "long month" display, MMMM or July vs. Jul to be consistent with the rest of Mattermost. Setting this as up for grabs.

[kamre]

@chenilim @jespino I am going to work on this issue. Do you think we can/should store UserSettings in the redux store?

[kamre]

It turns out that Card View uses moment.js formatting for the date and it has support for strings like MM/DD/YYYY.

But Card Preview on the board uses react-intl inside Utils.displayDate that doesn't support such format strings as MM/DD/YYYY.

@chenilim do we want to switch Utils.displayDate to moment.js with passing it locale somehow or try to fix react-intl usage for the desired date formats?

@asaadmahmood the recommended change tells to extend the date formats. Do I understand correctly that we want all 4 variants in the menu like this:

?

[asaadmahmood]

@kamre Hey, thanks for the message.
We only want MMM DD, YYYY
We can remove the set Date format input for now, and have that format be there by default.

But let's wait for @chenilim on that.

[chenilim]

Yup, thanks @asaadmahmood! After discussion, we decided to align with the current Mattermost behavior for now, i.e.:
To confirm, use the following date display everywhere we display a date:

• MMMM DD if in the current year, e.g. September 08
• MMMM DD YYYY if not in the current year, e.g. September 08, 2019

Remove the "Set date format" user setting for now. The above should be appropriate internationally.

On implementation, let's try to use react-intl instead of momentjs if possible.

Please LMK if anyone sees any issues with this. Thanks.

[kamre]

@chenilim skipping year is really easy with react-intl but it looks different in different locales:

Here first date is current year and so it is skipped. Is this what we expect to have?

Another big question is the input by user via directly typing something into the input element like here (its possible not to interact with calendar popup and just type date):

@asaadmahmood Do we need to support this and require users to input in the expected format?

This doesn't seem an easy task at all because formats are very different for different locales and parsing is not available inside react-intl as its just a wrapper for Intl that doesn't provide any locale specific format hints. Look at this discussion for example,

[chenilim]

Hi @kamre, the internationalized dates above look good to me. The key thing is the dates are unambiguous, which they appear to be.

(Updated after taking a closer look): As a workaround for entering the format directly, I propose switching to the MM/DD/YYYY or DD/MM/YYYY format when editing, which is the current behavior. So, let's keep the user setting for now, which will only affect the edit-time display. The broader issue here is that it's easy for the user to enter far-off dates quickly, and direct-entry seems to be the only way with this control.

Thoughts @asaadmahmood?

[kamre]

@chenilim @asaadmahmood I have implemented the proposed approach with different date formats for displaying and editing. Please look at #748, there are some sceenshots.