The current {node}.created and {node}.changed columns are often insufficient to meet the needs of publishing workflows. Take the following use case...
An author creates a new article on May 1. This article is edited several times, eventually being published on May 9. Any chronological article listing should now list the article's date as May 9. On May 15, a small typo is discovered. The article is then edited to fix the typo and saved, but chronological article listings should still list the article's date as May 9, since that is when it was originally published.
Currently there is no straightforward way of accomplishing this. Listing articles by creation date doesn't account for articles which are held in draft form for a time while being readied for publication. Listing articles by their modification date fails to account for articles which need minor corrections after they have been published.
Add a "published" timestamp column to the {node} table. When a node is saved, if {node}.status=1 and no publication date has been set, then set {node}.published={node}.changed. However, if {node}.published is not empty, then maintain the existing value.
Replace the current "Authored on" field, under the "Authoring information" tab on node edit forms, with a new "First published on" field. When the node edit form is loaded, if {node}.published > 0 than the existing value is displayed, otherwise the field is blank. If this field is empty when the node is published, a published date will be generated automatically on submission. If the user manually enters a value in the "First published on" field then it will be used in place of the default value for {node}.published, overwriting any existing value.
The default front page node listing—and its equivalent Views display—will sort on the new published date, instead of nodes' created date. Likewise, the submission information displayed on nodes will use the published date.
Minor changes to implement {node}.published, but nothing that should impact other modules, unless they want to use the new timestamp for something.
Needs work
11.0 🔥
Makes Drupal easier to use. Preferred over UX, D7UX, etc.
Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.
Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.
Related to the Views in Drupal Core initiative.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
What do we need to do to move this forward, I agree it is absolutely ridiculousness that a content/authoring first experience does not have a concept of a "published on" date. Updated on is nowhere near accurate for the vast majority of publications. Most people have resorted to implement this themselves.
So let's figure out a game plan to move this forward and get even a basic version into core.