The <lastBuildDate> element is wrong too, after #13008 things can be fixed in 4.0 due to the need for a B/C break with a public class property.

This still doesn't change the fact that nothing actually sets the build date or modified header correctly, which as noted in the linked issue is a bigger code change because it requires looping over all entries going into the feed to determine the correct date to set (versus using whatever time "now" is as is the current case).

Related issue #17192

@mbabker Doesn't it just require checking the first <item> node for the date/time and using that? The feed wouldn't be any newer than its latest item.

This assumes every component view class pushes data into the JDocument object in a dated order. The reality is components should be setting these attributes themselves and not looking for magic behavior in the framework to do it, but because every non-HTML based aspect of Joomla is treated as a second class citizen the odds of things being fixed correctly are slim to none.

@mbabker Since it appears this may never be resolved in the way you describe, is it worth a simple patch just for RSS to fix the header in the meantime?

Its not just the rss feed that shows the current date as the last modified date. The same is true of the http headers

See https://itoctopus.com/how-to-change-the-last-modified-http-header-in-joomla-free-plugin
and https://httpdot.org/howto/44-adding-last-modified-header-and-meta-tags-to-joomla-template

So if this issue, according to those sites, is solved with the code provided, is there any reason this hasn't been fixed on the core yet? Does that code impact anything else? It seems pretty straightforward so is a PR all that's missing here?

It would need to be a PR updating all the frontend component view classes to set the right data in the Document instance or headers in the app (since we should do it all and not just fix com_content). Just needs someone to do it.

It would need to be a PR updating all the frontend component view classes to set the right data in the Document instance or headers in the app (since we should do it all and not just fix com_content). Just needs someone to do it.

hmm just to be sure. What do you mean by "all the frontend view classes"?

Isn't it just this files:

./components/com_contact/views/category/view.feed.php
./components/com_content/views/category/view.feed.php
./components/com_content/views/featured/view.feed.php
./components/com_finder/views/search/view.feed.php
./components/com_tags/views/tag/view.feed.php
./components/com_tags/views/tags/view.feed.php

Or I'm getting it wrong?

If you aim to just fix the feed classes then sure. But shouldn't HTML documents be doing the same?

OK i have just found the code we need:

		// Pass the modified date to the document
		if ($this->item->modified)
		{
			$this->document->setModifiedDate($this->item->modified);
		}

But there is a problem. What is the expected behavior for multible items per page? Like the feed or the category list etc.

The code above also obviously just affects the header if the content is cachable at all.

I thunk it should be the date/time of the latest article publish/modification date/time.

I am deleting your advert @AdvanceShop

@zero-24 did you make any progress with this?

No. Feel free to take over if you wish. I currently don't have the time to dig deeper into this. Sorry