Please dont use bootstrap tooltips for this - they are horrible for accessibility.

Please look at the way the code is done for the search box and use the pseudo tip code for that

Is this screenshot wrong? Whats the point of a tool tip that shows the same as the text hovered over?

BTW I think we used to have this functionality and it was removed

Not to kill contributions, but personally, as I have already commented elsewhere:

The home dashboard is an overview of the RECENT happenings on a site therefore it MAKES SENSE that this screen should have relative dates.

On normal listing screens date stamps are better, and can be ordered etc,

And as you have said... "do we really need another option"....

Although I do agree a RELATIVE date should have a popover with the full timestamp - that makes sense.

Although I do agree a RELATIVE date should have a popover with the full timestamp - that makes sense.

I think if my memory is correct the problem was that the relative date was only for the first month and after that you got the real date and then the tooltip was a duplicate. But my memory might be tricking me

Although I do agree a RELATIVE date should have a popover with the full timestamp - that makes sense.

Do you mean in this way: Patch: ON, View enabled:

sorry, hv trbls to add screenshot ....

I mean like timeago for jQuery has been doing for a decade.

Please dont use bootstrap tooltips for this - they are horrible for accessibility.

Please look at the way the code is done for the search box and use the pseudo tip code for that

Done, thank you!

Is this screenshot wrong? Whats the point of a tool tip that shows the same as the text hovered over?

That's a good point. Technically, it's not the same (in case of absolute formatting and the same date format, the tooltip would not be shown), but it's very close. I added the tooltip for situations where we use a less precise format like the second one you showed here: #33023 (comment)

I think if my memory is correct the problem was that the relative date was only for the first month and after that you got the real date and then the tooltip was a duplicate. But my memory might be tricking me

I don't know if that was the reason back then, but it is an issue, yes (see discussion point 2 in the description). I could try to detect and avoid this case, but then we would have an inconsistency between "two days ago (tooltip: 2021-04-04 19:05:00)" and "2021-02-02 19:00:00 (without tooltip)".

Not to kill contributions, but personally, as I have already commented elsewhere:

The home dashboard is an overview of the RECENT happenings on a site therefore it MAKES SENSE that this screen should have relative dates.

On normal listing screens date stamps are better, and can be ordered etc,

And as you have said... "do we really need another option"....

As discussed in #31675, we do need another option, at least for the list case, because different users have different preferences there. Why not use one option for all instead of adding such an option everywhere?

Although I do agree a RELATIVE date should have a popover with the full timestamp - that makes sense.

Do you mean in this way: Patch: ON, View enabled:

that's what I would expect - yes.

Whenever a relative date is displayed, one should always be able to see the actual date in a popover

I know what 8 mins ago was - that is easy, but when it says 3 weeks ago, I need to know what date that was... that's not easy to quickly do in ones head.

The other point:

I think if my memory is correct the problem was that the relative date was only for the first month and after that you got the real date and then the tooltip was a duplicate. But my memory might be tricking me

@ Harmageddon wrote: I don't know if that was the reason back then, but it is an issue, yes (see discussion point 2 in the description). I could try to detect and avoid this case, but then we would have an inconsistency between "two days ago (tooltip: 2021-04-04 19:05:00)" and "2021-02-02 19:00:00 (without tooltip)".

sorry, I can't send screenshot via Github, therefore here:

I have tested this item ✅ successfully on 9bbe5e6

This patch works as described.

After applying the patch a new option appears in the User Profile. When "Show Relative Dates in Lists = NO" is selected, the dates in the action logs appear as absolute dates. Otherwise they appear as relative dates.

@Harmageddon sorry but this is not quite ok. Do NOT use HTMLHelper here, use JLayout, eg create a file in layouts/joomla/html/relative-date.php with content:

<?php
/**
 * @package     Joomla.Site
 * @subpackage  Layout
 *
 * @copyright   (C) 2016 Open Source Matters, Inc. <https://www.joomla.org>
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */

use Joomla\CMS\HTML\HTMLHelper;
use Joomla\CMS\Language\Text;

defined('_JEXEC') or die;

extract($displayData);

/**
 * Layout variables
 * -----------------
 * @var   boolean  $forceRelative
 * @var   string  $format
 * @var   string  $date
 * @var   string  $showAbsoluteDate
 * @var   string  $unit
 * @var   string  $time
 */

$user = Factory::getApplication()->getIdentity();

if ($user === null)
{
	$useRelative = true;
}
else
{
	$useRelative = $forceRelative || $user->getParam('use_relative_dates', true);
}

// Format for the full / absolute date display.
$formatAbsolute = Text::_('DATE_FORMAT_LC6');

if (!$useRelative && $format === $formatAbsolute)
{
	return HTMLHelper::_('date', $date, $format);
}

$dateMain = $useRelative ? HTMLHelper::_('date.relative', $date, $unit, $time, $format) : HTMLHelper::_('date', $date, $format);
$dateAbsolute = HTMLHelper::_('date', $date, $formatAbsolute);

if ($showAbsoluteDate === 'tooltip')
{
	echo '<span>' . $dateMain . '</span><time role="tooltip">' . $dateAbsolute . '</time>';
}

if ($showAbsoluteDate === 'below')
{
	echo $dateMain . '<time class="small d-block">' . $dateAbsolute . '</time>';
}

echo $dateMain;

and then call it like:

<?php echo \Joomla\CMS\Layout\LayoutHelper::render(
	'joomla.html.relative-date',
	[
		'date'   => $item->log_date,
		'format' => Text::_('DATE_FORMAT_LC5'),
		$showAbsoluteDate = 'tooltip',
		$time = $now,
		$forceRelative = false,
		$unit = null
	]
); ?>

The reason is simple: using JLayout is easily overridable for front end devs. HTMLHelper need a plugin in order to be overriden

Actually, reading #33023 (comment) I think the idea of processing this data in the server is wrong, should be done on the client-side using Temporal: https://github.com/tc39/proposal-temporal and a simple web component.

Sorry, the JS is not temporal but https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat

Actually @PhilETaylor I think your PR that introduced the relative dates is wrong, we can do this using the browser native power... ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat
)

I have tested this item ✅ successfully on 9ccc859

This worked. I had to learn about setting up a menu item for Privacy --> Create Request.

I have tested this item ✅ successfully on 9ccc859

It's still draft and so tests don't count.

@Harmageddon @dgrammatiko Is there anything left to be done or clarified regarding the above discussions? Shall I set the "Updates Requested" label?

Is there anything left to be done or clarified regarding the above discussions?

I'll stick to my opinion that this should NOT be an HTMLHelper thing but a JLayout, HTMLHelper should be used only for PHP functionality, if anything is echoed then that should be done directly with Layouts

I see the point in making it a layout, but haven't found the time yet to convert and test it. I'm not sure about the web component proposal though, because apart from shifting the translation from our own translation files to the browser, I don't see great advantages, as we need to do the same calculations as far as I understand.

Thank you for testing this already, but as @richard67 said, this is still in draft state because of the discussions and open points listed above. As soon as it is ready for testing, I'm going to mark it as such.

Shall I set the "Updates Requested" label?

Does that make any difference while the PR is in draft state? If yes, feel free to do so.

Does that make any difference while the PR is in draft state?

Right, draft state is sufficient.

@Harmageddon @wilsonge @bembelimen Would it make sense to move this PR to 4.1?

I never thought something as simple as relative dates could be as controversial as it has been.

Thanks for the link for Intl.RelativeTimeFormat - I have certainly never seen this before, and Regli use JavaScript libraries (timeago.js and jQuery) ones to do this.

@Harmageddon @wilsonge @bembelimen Would it make sense to move this PR to 4.1?

As I sadly don't have the time right now to proceed with this, I assume it's not going to make it into 4.0. So yes, I'd re-target this for 4.1 and come up with a more consistent and overridable solution when I find the time.

This pull request has automatically rebased to 4.2-dev.

The feature is interesting, but due to inactivity we are closing this draft. You can open it again, when you have the time to rework it.

@rdeutz

#PROD2020/024 - There shall be no indiscriminate closing of Issues or Pull Requests
Closing of Issues and Pull requests PR's shall NOT be done without underlying rationale and individual reasoning in the Issue or PR. Elapsing of a time period, inactivity of the submitter are examples that do NOT constitute valid reasons in and by themselves.

This motion is undicided and the maintainers have decided how we will do the Handling of abandoned PR’s.

The maintainers team will check older (older means, no relevant activity for a certain time frame, 18 months) Pull Requests and discuss if a Pull Request should be closed.

This motion is undicided and the maintainers have decided how we will do the Handling of abandoned PR’s.

My apologies - I missed thaat part