Friendly time is silly for longer periods

[mrclay]

Describing times as "2142 days ago" is embarrassingly bad UX. When these are seen in a meeting they're rightfully mocked.

After 30 days: "May 14"
After a year: "June 2015"

[iionly]

so something like https://elgg.org/plugins/869364

[jdalsem]

Yep... switching to dates after a certain period makes more sense...

[propertunist]

the problem with using dates is that there is no support for local time in elgg. so you will always see the time for the timezone that the server is configured for. without adding support for local time, my only suggestion is to add different time periods to the friendly time label system. e.g. instead of 366 days ago, you would see '1 year and 1 day ago' or something similar. each site will have different requirements and some might prefer to just see '1 year ago' and leave out the number of days.

[jdalsem]

We currently already show the textual date as a mouseover... the timezone issue is real, but could be separated from this issue... momentjs comes to mind

[propertunist]

right ok. i just tested iionly's plugin and i agree, it solves the problem since it doesn't display times with the dates. the other versions of the friendly time plugins i have used were showing times too.

[iionly]

Even when not showing the time but only the date there would still be the same possible error with timezones not showing the correct date if you expect the output to take into account your local timezone (that might be more or less different to the server time). But I think this is a matter for a different issue because the friendly time output is first of all a matter of output format. As long as timezones support is not implemented the output format can be switched depending on the time difference between now and an items creation/modification time in many ways. The question is if this adjustment is to be added to core as a new feature or if it would be enough to refer to a 3rd party plugin that uses the 'format', 'friendly:time' hook to do this job.

Additionally, Elgg supporting different timezones for every users is a much larger issue to deal with (as you not only have to take into the account the details of output but also date/time input of users because these data might also be displayed using friendly time views). The output of user input with taking into account timezones might be a major hassle though. Think about existing content that has been saved without a timezone shift or think about a user changing the user-specific timezone. Could get quite messy. But I think it's really something for a separate issue (if there's not yet such an issue). After timezone support would be implemented it might be necessary to make adjustments in the friendly time output (or just in the data available in the hook) if Elgg core does output more than just "X days ago". Additionally output formats taking into account the user language might be nice to have then, too.

[mrclay]

More Elgg/www.elgg.org#66

[juho-jaakkola]

Crazy idea: Let's allow language files to define the full format.

This could be anything supported by date() function, e.g. "F Y" (January 2016):

$format = elgg_echo('friendlytime:format:within_year');

All textual representations (in this case "F") are parsed from the $format and replaced by translated strings:

if (strpos('F', $format) !== false) {
    $month_number = date('m', $time);
    $replacement = elgg_echo("date:month:$month_number");
}

For this we would need a class that maps date format characters to the translations and performs the replacement.

[mrclay]

language files to define the full format

Feels like something for site settings. Let's ask @beck24 or his coworker if he knows how Drupal handle date formatting + I18N.