Add date-only date formats, and use in Announcements Feed

Going to have and look at this later. Not sure why migration test had to be updated

Seems like a fine addition and no objection. I didn't see any recipe that was installing datetime formats

Also doesn't feel like something that would need test coverage as just offering more options.

Very minor but I'm wondering if these could be e.g. 'Medium date (without time)', rather than starting with 'no time'.

Since this is user-facing tagging for product manager review.

@ressa yes it changes out of the box behaviour so I think it could use it.

Seems fine from product perspective. I've wondered several times myself why we don't have these out of the box 🥲

Thank you @lauriii!

Just a few questions

Why is this change limited to new installs?

I did a fresh install with this MR and there are now two identical formats, 'Olivero Medium' and 'Short date (without time)'. I think that is confusing and should be addressed somehow.

And, can we use a more positive description, "Short date (date only)" instead of "Short date (without time)".

Setting to NW for responses to the above.

• I'd replace "Olivero Medium" with the new one, here or maybe even on a follow-up.
• Should existing installations also get these date only formats, via an update hook? Yes, if there aren't pre-existing date formats with the same machine names.

Good idea to remove the Olivero date format. My main concern with this issue is that it's a lot of default date formats, but if we're able to start getting rid of one-off ones, that's a good trade-off.

See MR comments.
Also tagging for required upgrade path tests.

I don't think we need an update here, they can just be available on new sites. Even if existing sites don't have formats with the same names, they may have all kinds of custom formats already created which are similar, and then suddenly these new ones would appear alongside them. Similarly we often don't even fix arguable bugs in shipped views like admin/content in update paths, because there is a higher chance of breaking a site than fixing it.

Just came back to this. My question,"Why is this change limited to new installs?" was truly a question. It was not an implication that any work was needed to change that decision. Apologies for the confusion.

Oh, really? Then 🚀 ship it. @pameeela said this already, but I was pretty sure this was one of the core gates.

That means we need to actually remove that upgrade from this MR and we're done.

We don't need upgrade tests if there's no upgrade. Removing tag.
@ressa For the sake of learning, see https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd...

Updated issue summary.
Only left: Revert

Tested this locally and found the sorting in the listing a bit weird. I think it would be better to prefix the labels.
I won't do it myself so I can still RTBC.

PS: don't try to test on the MR tugboat because it doesn't trigger a new install.

Thanks for the quick response 😊

This is probably a duplicate of #2960821: Add default date formats without time but this has obviously had much more recent discussion. Perhaps someone could credit @dead_arm for the original issue I've just closed.

Do we need a CR for the new formats and the removal of Olivero Medium? We had one last time formats changed - https://www.drupal.org/node/3467774

In general I agree with removing Olivero Medium, but isn't it possible there are existing configs depending on this? I found at least 38 references in code after filtering out the cruft - https://git.drupalcode.org/search?group_id=2&scope=blobs&search=olivero_...

These tend to be in recipes, formatter config, views fields and tokens.

I think maybe we need a follow up to deprecate and remove it.

I'm not sure how we deprecate a config entity. But definitely we should have a specific change record for the olivero date format.

In #44 I expected that we would do the deprecation (but not the removal) here. That's why I suggested a new change record.

FWIW I think deprecation should be a separate issue and not even discussed here, make this easier to get in.

Tweaked the CR slightly for 11.3 rest seems fine to me!

I removed 'proposed' from the CR and added a screenshot to the issue summary.

Everything appears to be in order here.

I can see adding one of these new formats, but adding three of them is essentially almost doubling the number of date formats. Perhaps we should just pick one to include? I find the new list kind of overwhelming. I think this would need usability review in addition to product signoff. (Meaning, we would want to add before-and-after screenshots and then tag it for usability review.)

Also, given that these are only being added to new installs, but we are also changing the production Twig template for the announcements feed, that could be a problem, no? So that might be a reason we actually would need an upgrade path, at least for the one that Announcements is now expecting to exist. No?

If folks are comfortable with adding just one date-only format, that change can be made and then we can go for a usability review. Otherwise, if folks feel strongly about adding all three, we should add the before screenshot and tag for usability review now.

#56: For context, this came from #3490066: Add shorter date format (without time) and start using in announcements feed, which came from Drupal CMS 1.0 dashboard designs (#3489989: Announcements date format in Drupal CMS Dashboard)

We needed just one date format. Before that, announcements had the same need, which happened in Olivero, because it didn't make sense to show the time when relevant announcements are quite spaced in time.

Then it was about adding the 3 different date formats for consistency, which felt interesting.

This might be a very small thing and even feels embarrassing referring to the strategy, but #3533440: Drupal Core strategy: July 2025 mentions:

What ships with Drupal Core?
[...]
2. Ensure consistency and/or high-quality:

* We add a feature to Drupal Core when it ensures consistency across all Drupal sites, or when it helps avoid contributed modules competing (reduce fragmentation).

Having each module (like core announcements, Olivero, dashboard, Drupal CMS, or any of the future site templates) providing a single (or a couple of) date format(s) for fitting their needs can be even worse in terms of an overwhelming amount of date formats, plus producing design inconsistencies.

Having these three would reduce the chances of that.

+1 for adding all 3

NW for #56:

Also, given that these are only being added to new installs, but we are also changing the production Twig template for the announcements feed, that could be a problem, no? So that might be a reason we actually would need an upgrade path, at least for the one that Announcements is now expecting to exist. No?

I installed standard profile on 11.x HEAD, then applied the patch from this branch and ran db updates. Before the patch the dates looked like "19 Jun 2025 - 05:05" and after like "Thu, 19 Jun 2025 - 05:05". This is because \Drupal\Core\Datetime\DateFormatter::format uses the "fallback" format if the format doesn't exist. So while we're not breaking anything, we are making it worse for existing sites. So we should probably do an update hook to install one or all new formats, but only if there isn't an existing format with the same name.

In #33 we were told no upgrade path needed, which we had already written (see #36).
Now we are at 60 comments for amending some date formats.

I still think that adding all the formats to existing sites would be confusing (to be honest I also still think this issue could just add the one date format instead of three but I am neither a UX nor product manager).

If we need to add exactly one new date format, checking for existing formats with the same name, we could do that - but IMO that should only happen in the announcements feed module then, so that it only gets added for sites with that module enabled. This would not be the same update as the one that was removed after #33, maybe some of the logic can be re-used though.