Post Date block always show the accurate Last Modified Date

[TimBHowe]

What?

Remove the if statement preventing the Post Date block from returning an empty value when the Last Modified Date is used and it matches the Published Date.

Why?

If you add a label before the Post Date block and you are using the Last Modified Date if is the same as the publish date then it doesn't display on the front end despite being shown in the editor on the back end.

This is another alternative solution to the issue mentioned above and the other pull request I made here: #61920
For this issue: #47738

This being subtractive should be simpler to merge and act as a temporary solution until a Bit solution can be created.
#39831
#61920 (comment)

This does cause an issue...
If the publish date is set in the future to schedule the post the Publish Date and Last Modified Date will show the post was last modified prior to being published. While this is true it may not be ideal for UX/UI.

How?

Removed the if statement here: https://github.com/dsas/gutenberg/blob/5b95e96a90aac522c6df73349930144b89b53dfa/packages/block-library/src/post-date/index.php#L38

Testing Instructions

1. Create a new blog post
2. Add a Group block to create a Row
3. Add a Paragraph block with the text: "Posted On:"
4. Add a Post Date block with the "Display last modified date" toggle disabled
5. Add a Paragraph block with the text: "Updated On:"
6. Add a Post Date block with the "Display last modified date" toggle enabled
7. Save the post and view the post. Both should appear with the same date.
8. Update the publish date to the past. Both should appear with the same date.
9. Update the publish date to the future will schedule the post. Both should appear with the same date.
10. Update your test servers system clock to past the future date. Both should appear with the same date, but this might be seen as an issue with the Publish date is after the Modified date.

Screenshots or screencast

Example of potential issue:

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Status] Stale, First-time Contributor, [Block] Post Date.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: TimBHowe <timbhowe@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: ockham <bernhard-reiter@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @TimBHowe! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[Mamaduka]

I think this was resolved by recent refactoring such as #70585.

cc @ockham

[ockham]

I think this was resolved by recent refactoring such as #70585.

@Mamaduka I'm afraid not -- I tried to keep the block as consistent as possible with its previous behavior. In practice, while the logic to provide the last modified date was moved to the newly introduced core/post-data source, I included the conditional that will hide it if it is before (or equal to) the publish date.

[Mamaduka]

It looks like the condition was introduced in #46839. There's also an issue to resolve this particular case - #57915.

I think the patch needs refreshing, so it's applied to the correct place after recent refactorings.