Which one is better, "a day ago" or "1 day ago"? @Pginer-WMF

See also T94648#1178640 wherein I researched a large number of other websites.
The community is strongly in favour of the second option that krinkle mentions, but use a mouseover for the elapsed time rather than replacing anything. (or optionally: show both, for 1-14 days, per my research)

In T111596#1746745, @SBisson wrote:

Which one is better, "a day ago" or "1 day ago"? @Pginer-WMF

In this context, I think it makes sense to go with a human-readable option. My preference is in this order: "yesterday", "a day ago", "1 day ago".

For other contexts where data is more compact or aimed at vertical scanning (e.g., notification panel or tabular data) a compact representation such as "1 day" may work better.

Note that "yesterday" may not be the same as "a/1 day ago": yesterday refers to the day prior to the current day.
If now is 1 past midnight, 2 minutes ago is yesterday. If now is 1 minute before midnight: 47 hours ago is also still yesterday.

Since all other relative times are "x seconds, minutes, ... ago", I would stick with that trend. Mixing "tomorrow" in with those might get confusing.

(Merging from T11804)

The translations for Urdu's timestamp messages, are correct during load, and then change to English once JS is loaded.
E.g. https://www.mediawiki.org/wiki/Talk:Sandbox?uselang=ur

@Catrope noted in 110934:

I am told Moment doesn't support qqx, so it's not super easy to figure out which message key is being used. I suspect there are two message keys for no good reason. Let's see if they can be found in lv.json.

@Mattflaschen noted in IRC:

it's getHumanTimestamp (from core) on the server and moment on the client.

Note: Based on the tasks, and large quantity of editor feedback, and the extensive external site research I did, that is linked from T94648: Examine the use of Elapsed vs Exact timestamps in Flow,
and the related issue in T102728: Flow does not respect time format and time zone preferences in JS mode...
I still strongly recommend simply changing everything to either:

1. use Exact timestamps, and retain Elapsed timestamps as a tooltip.
2. use Exact timestamps, and for the first 2-14 days, append the Elapsed timestamps in brackets. e.g. 08:26, 3 Octember 2018 (UTC) (2 days ago)

We discussed this in today's meeting, and the outcome was that we want to try out something similar to @Quiddity's option #2: always showing both the absolute and relative timestamps, separated by a bullet or similar. Remaining concerns that we should discuss once that has been prototyped:

• Should we always show the relative timestamp, or only for "recent" things (e.g. less than 2 weeks old)?
• Would this mean showing too much information?

In T111596#1797177, @Catrope wrote:

We discussed this in today's meeting, and the outcome was that we want to try out something similar to @Quiddity's option #2: always showing both the absolute and relative timestamps, separated by a bullet or similar. Remaining concerns that we should discuss once that has been prototyped:

• Should we always show the relative timestamp, or only for "recent" things (e.g. less than 2 weeks old)?
• Would this mean showing too much information?

We also decided to always use only exact for the server/no-JS.

Would this mean showing too much information?

This is my main concern. I recreated the proposal with a quick in-browser HTML editing:

• Especially if we plan to use a full timestamp the whole information element seems too prominent.
• Presenting two information items gives the impression of being two separate pieces of information (especially on the topic header where they are next to the number of replies which actually is a different piece of information)

If the usecase we are willing to support is that of copying the timestamp we can also explore the following options:

• Provide the detailed timestamp on the detailed view of posts but keep short relative time for recent items when viewing them in a flow board. While relative times (10 min. ago) provide a useful reference when scanning multiple posts, it could be acceptable to show a more exact representation when viewing the specific post view (through the permalink).
• Make relative timestamps to become the full text when copied but not on display. We may be able to use the better kind of content for each use: short for reading, exact for copying/quoting/archiving. In this experiment I illustrated one possible approach in a very hacky way (but engineers may come with a more elegant solution in this direction).

Another question is whether the timestamp should still be a link if we consider that facilitating copying it is such an important usecase to support. In any case, I think it would be great to know the specific details of the "users copying the timestamps" usecase based on some examples. Anyone with more details feel free to add them.

@Pginer-WMF Re: Copying - This is only a minor use-case. (Fwiw, Timestamps are copied (in whole, or in part) for all sorts of reasons, and in a wide variety of circumstances. The most common is probably when replying within the same long topic, where (for example) Alice would write something, and then Bob would refer to "in your post above at 15:22, 17 November, you wrote [...]" or when referring to another post elsewhere without needing the specificity of a link "in your 15:22, 17 November post at my talkpage, you wrote [...]".)

The first main reason for changing this, is being able to distinguish between closely time-grouped posts, without having to hover over each timestamp to see the exact times.
E.g. If there are many posts (in 1 or more topics, at 1 or more pages), and the information in some of them contradicts others, then having them all labelled "1 hour ago" or "1 day ago" is not useful, and I have to mouseover (and then mentally keep track of) each timestamp, to see exactly what sequence they occurred in.

The second main reason for changing this, is so that actions on the visible page, can be easily correlated with the actions in the (history/contribs/RC/watchlist), which all use exact timestamps.

Re: "seems too prominent" - I think the grey color of the text mostly solves that.

Re: "the impression of being two separate pieces of information" - In the meeting we discussed whether or not brackets would be suitable for this - e.g. (2 days ago) 08:26, 3 Octember 2018 (UTC) - and there were concerns about possible i18n issues with this. I've investigated the docs, and checked watchlist examples in dozens of languages (brackets are used prolifically and identically in all of them, it seems), so I don't think this is a concern; however I've asked for confirmation.

Note, we can also (potentially?) use month abbreviations. At least, they're listed at https://www.mediawiki.org/wiki/Localisation#What_can_be_localised

In T111596#1801734, @Quiddity wrote:

The first main reason for changing this, is being able to distinguish between closely time-grouped posts, without having to hover over each timestamp to see the exact times.
E.g. If there are many posts (in 1 or more topics, at 1 or more pages), and the information in some of them contradicts others, then having them all labelled "1 hour ago" or "1 day ago" is not useful, and I have to mouseover (and then mentally keep track of) each timestamp, to see exactly what sequence they occurred in.

This is even worse when reading an old discussion, because every post is marked as "3 months ago".

I think we are in the same page with respect to the issues of relative timestamps for old posts. The "3 months ago" illustrates clearly that it is impossible to properly order the items in time even if they happened several days apart. I'm totally fine in using exact time for items at that scale. The bigger the time scale the useless relative time becomes.

However, for recent posts (from 1min. ago to 23h ago) I think the story is different. Relative reference of time provides a quick sense of time orientation, and that advantage can be lost if the user has to process a verbose timestamp.

I think it would be good if we could take advantage of context for conveying the information in a more concise way, a bit closer to how a human would do when telling time. We present the basic time information (hours and minutes) and either include (a) the relative time or (b) the year and/o month details when they are relevant (i.e., omitting the current year or month). Some examples below:

• 9:25 (1 min. ago) - for recent than one hour posts.
• 8:26 (1 hour ago) - for recent than a day posts.
• 8:26, 1 Oct. - for older than a day posts.
• 8:26, 3 Oct. 2014 - for older than a year posts.

Does the approach described solve the scenarios mentioned by @Quiddity above?
I think that when comparing related posts (reason 1) or with a given list of timestamps (reason 2), the missing information (current month or current year) can be easily implied without breaking those processes.

We need to evaluate if the approach is technically feasible (i.e., making use of month abbreviations and using variants of the time formats that include moth and year information only when relevant, while keeping everything localisable), but I think it is worth it since reading the list above seems more fluent to me than the equivalent one below:

• (1 min. ago) 09:25, 3 October 2015 (UTC)
• (1 hour ago) 08:26, 3 October 2015 (UTC)
• (2 days ago) 09:25, 1 October 2015 (UTC)
• (1 year ago) 09:25, 3 October 2014 (UTC)

In T111596#1804185, @Pginer-WMF wrote:

I think we are in the same page with respect to the issues of relative timestamps for old posts. The "3 months ago" illustrates clearly that it is impossible to properly order the items in time even if they happened several days apart. I'm totally fine in using exact time for items at that scale. The bigger the time scale the useless relative time becomes.

However, for recent posts (from 1min. ago to 23h ago) I think the story is different. Relative reference of time provides a quick sense of time orientation, and that advantage can be lost if the user has to process a verbose timestamp.

I think it would be good if we could take advantage of context for conveying the information in a more concise way, a bit closer to how a human would do when telling time. We present the basic time information (hours and minutes) and either include (a) the relative time or (b) the year and/o month details when they are relevant (i.e., omitting the current year or month). Some examples below:

• 9:25 (1 min. ago) - for recent than one hour posts.
• 8:26 (1 hour ago) - for recent than a day posts.
• 8:26, 1 Oct. - for older than a day posts.
• 8:26, 3 Oct. 2014 - for older than a year posts.

Sounds good to me. This is similar to what gmail does actually: for your examples, gmail would render 9:25am, 8:26am, Oct 1 and 10/3/14 respectively.

If we can pull this off i18n-wise, let's do it.

I'm with Quiddity. Full timestamp with temporary or permanent relative time. 99% of the time the timestamp disappears into background, but it is prominent and awkward when you do want the full version and it's not there.

I disagree with:

• 9:25 (1 min. ago)
• 8:26, 1 Oct. (1 day ago)
• 8:26, 3 Oct. 2014

That shorten things, but I think it actually increases the cognitive load. The brain loves to optimize to consistent patterns. You've got three different formats there. First the brain needs to categorize which format it's seeing, and then there will be a bit of "neural code" specialized for handling three different cases. For an interesting comparison, imagine writing software to read dates with that sort of mixed format.

Thanks @Alsee for you feedback.

That shorten things, but I think it actually increases the cognitive load.

That depends heavily on the specific scenario. For example, when using Gmail, I found my experience quite fluent when scanning a list of items and the format changes to take advantage of context (e.g., 7:15, 2:45 ... Dec 1, Nov 25 ... 3/4/14). The use of chronological order may be alleviating those changes of format since items with a similar format become close to each other making the transition more fluent.

In our case, we are also keeping a compatible structure where additional elements are added as they are relevant. I'm not sure that moving from "1 Jan" to "31 Dec, 2014" qualifies as a radical change of format requiring a reorientation effort. Having said that, I think it is worth checking and I think it would be worth it to view how the model works with real content.

As I said earlier, for that is important to identify the different scenarios. Can you provide more details on how you access timestamps currently and for which purpose.

it's getHumanTimestamp (from core) on the server and moment on the client.

So this bug boils down to the old issue of making Moment use Globalize and making Globalize use some standard library (with CLDR data) and making MediaWiki core's getHumanTimestamp match that? See https://www.mediawiki.org/wiki/Globalize and T66430: getHumanTimestamp issues (tracking).