Date Block: Format options can have latest date

[Rishit30G]

Description

In the ‘Date Block,’ the current date formats available in the block settings panel are example dates. However, it would be more intuitive and enhance the user experience to display the latest date instead. This ensures synchronisation when working with real-time content, as most of the users tend to add this block when working with the post before publishing, so getting to see the current date that they are going to place from the dropdown makes sense.

Additionally, it improves the display of relative timestamps (e.g., “a second ago,” “2 minutes ago”), aligning them with the actual post update time for a more cohesive experience.

Step-by-step reproduction instructions

1. Add a new post
2. Insert a Date Block
3. In the block's settings panel, locate the Choose a format option.
4. Click on the dropdown to reveal various date format options.
5. Notice that the options shown don't have the latest date/time.

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.7.2
• Gutenberg 20.3.0-rc.2
• Mac OS
• Chrome

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Rishit30G]

I came across this comment which was earlier used with the example date
Ref: https://github.com/WordPress/gutenberg/pull/62298/files#diff-a81f243f8ac38c659d64de0894c81e2ea49caa131c13b3807c1ed74367c81326L16-L20

// So that we can illustrate the different formats in the dropdown properly,
// show a date that has a day greater than 12 and a month with more than three
// letters. Here we're using 2022-01-25 which is when WordPress 5.9 was
// released.
const EXAMPLE_DATE = new Date( 2022, 0, 25 );

Two issue with the current date approach is handling the month of ‘May’ and handling months/dates like '2/2/2024' / '11/11/2023', but it can be solved if we add some formats like DD/MM/YYYY at the right end of the dropdown options.

Or if we really want to avoid the current date approach, then we can also consider WordPress 6.7 release date 12th Nov 2024 like it was done previously with WordPress 5.9, as in the current implementation the date is fixed to 20, and the month is set to three months before the current month. 🤷🏻

I’m still unsure which one would be the best approach. Personally, it seems like having the current date can be considered, but we need to consider the potential caveats. I’d appreciate some discussion before moving forward with any PR.

Screenshot of the current date implementation:
The time zone has been updated to match my UTC offset.

[code-with-mehedi]

@Rishit30G I think we could potentially have a combination of both solutions: show the current date but with an option to cycle through additional formats like DD/MM/YYYY, and maybe even the ability to toggle between "real-time" and "example" dates. This way, users can still see the example date if they prefer, but they’ll also have the flexibility to work with the current date.

Would love to hear what others think before we move forward with a PR!

[ntsekouras]

I was so confused why May could be a problem, but then I realized the 3 letters issue 😄

IMO the example date logic for DateFormatPicker is good in order to properly showcase the available formats without possible confusion from current date (ex May) and the example used is also displayed as a help text in the toggle control.

The actual block in the editor that uses DateFormatPicker can serve as the preview. I think we should close this one. What do you think? I'll also cc @t-hamano and @Mamaduka for thoughts.

[t-hamano]

Thanks for the ping.

Personally, I would suggest the following changes:

• Always show the latest date
• Remove the variation that includes the month abbreviation (M) and add another variation
• Display the format string to the right of each option

Remove the variation that includes the month abbreviation

The current logic tries to use months with different full and abbreviated names, but this only works in the English locale. In non-English locales, months other than May may have the same full and abbreviated names. Furthermore, Japanese, Chinese, and Korean do not have abbreviated month names at all. Therefore, the very attempt to distinguish between full names and abbreviations may not be ideal.

English	Japanese	Korean	Chinese

In other words, what I'm proposing is that we might be able to draw inspiration from the core UI:

[ntsekouras]

The current logic tries to use months with different full and abbreviated names, but this only works in the English locale.

Of course.. That's great feedback @t-hamano, thank you!