Option to display absolute dates and times instead of relative, e.g. "25 days ago"

All dates in the web interface are displayed relative to today. It would be nice if there was an option to show the exact dates and times instead, or an option to automatically display dates if the timestamp is a set amount of time ago. Something like '2 hours ago' is useful, but 'about a month ago' is already a lot less useful (to me).

Also asked here: https://github.com/gitlabhq/gitlabhq/issues/9600 and here: https://groups.google.com/forum/#!searchin/gitlabhq/date/gitlabhq/4ElyH670i8o/P_Ax2plw1g0J

Added ~14213 label

Is the mouse over the "about a month ago" or "2 hours ago" not enough?

For example

It would be nice to have the option to choose between timestamps and relative dates based on a user setting. Both values are there anyways, so it should be no performance issue.

I was just looking for a commit from a specific date. Hovering over each 'updated a month ago' was tedious.

+1 this would be very useful. hovering over the dates is too slow. the main use case i have for this is when an incident occurs and i want to find out what changes happened around that time.

+1 for this feature.

Hi,

First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.

This issue will be marked for closure, as it meets the following criteria:

• Created over 1 year ago
• Labelled as a ~"feature proposal"
• Unscheduled (not associated with a milestone)
• Less than 10 upvotes

Thanks for your help and please raise any new feature proposals as a new issue.

/cc @markglenfletcher

added auto updated awaiting feedback labels

We are reverting the above policy regarding old, feature proposals until we find a better solution. Sorry for the noise.

The issue will no longer be marked for closure.

removed auto updated awaiting feedback labels

added auto updated potential proposal labels

changed title from [feature proposal] option to display dates and times instead of '25 days ago' to Option to display absolute dates and times instead of relative, e.g. "25 days ago"

Thanks for the proposal and votes. Would this be an instance level setting or a user-level preference?

/cc @jramsay

mentioned in issue #8 (closed)

mentioned in issue #14216 (closed)

@markglenfletcher setting this as a user preference would be good. So everyone can decide what format he/she want's to see.

can we add customer to this, please?

@jramsay We could open this for a ~"Community Contribution"

Can we make our relative date handling smarter or make the absolute time roll over more useful rather than introducing a user preference?

/cc @victorwu since this would impacts ~Discussion

added UX label

@sarrahvesselov : I forget if we've had previous discussions about this before. But this should be a solved problem for web apps such as ours. Thoughts?

I have vague memories of discussing this in another issue somewhere, but there were no decisions to deviate from our current system @victorwu. I agree this should be documented in our usability patterns. I will create an issue.

gitlab-design#139 (closed)

mentioned in issue gitlab-design#139 (closed)

I think it's more convenient to divide between the comments in vertical timeline (today, last week, last month and last year), and per each single comment display it's exact date.

Ex:

Today

Comment 1 Posted on 12:33 pm

Comment 2 Posted on 14:33 pm

Last week

Comment 1 Posted on 9:00 am

comment 2 Posted on 14:00 pm

+1 We would like this feature too. hovering the dates is nice but not useful for comparison.

can we add "customer" label to this please?

added customer label

marked this issue as related to #34327 (moved)

Please banish timeago.js completely. It is broken, and it breaks gitlab (which is a wonderful product in most other respects). The timeago.js timespans will cost users confidence at least.

Some precision loss of the minimal natural language relative time span may be fine for twitter or facebook. It may even be acceptable for some uses in gitlab. But the timespans in gitlab have real issues, not just bugs and imprecisions.

It is horror to imagine that a developer, after seeking a reliable platform for its precious code, discovers first time that platform itself wrecks havoc in and amongst all things having timestamps in its own as well as in developers assets, data and states. Yes, it is just a frontend issue, but confidence fades anyway.

timeago.js..

• has stupid rounding rules (actually it seems like it truncates all remainders - this is where days, weeks, months, sometimes up to 364 days at once perish in the void, as reported in #34327 (moved) and others),

• is by design limited to deliver a representation consisting of one integral number, at highest available scale that results in a numerical value > 0, combined into a localized text with appropriate unit and direction ("X units ago" vs "in X units").

• side note: this preference for highest scale will lead to prefer the lowest numerical precision in each case.

• has no sane rules to handle the fuzzy zones where scales touch. Assume: we are in the "days zone", we will need 7 full days to overflow a "1" into the "weeks zone". Now what should we do with days 8,9,10,11,12 and 13 that follow now? We already leaved "days zone" and can only spit out one integral in one zone, and next +1 in "weeks zone" is at day 14. So, we throw it away.

Probably anything not based on timeago.js will improve the timestamp situation of gitlab.

For me, personally, the most important and fragile time range starts at day 8 in the past down to about 8 weeks earlier). Lets call this the "hot zone", my working zone. In this range I check status, histories, issue reports, merge requests, prepare projects, process merge requests, resuscitate and work into a project that was on ice meanwhile. take over or hand over projects from/to others in team.

This is the range that is most relevant for me. And this is where timestamps are most relevant and should have a sane precision, days would be fine.

But in this range, the timeago.js timestamps of EACH 6 out of any 7 consecutive DAYS ARE off by at least 1 day, up to 6 days. And this not by accident, it is by pure design.

This is insane.

And it is insane in every other time range, it is broken.

Isn't it ironic?

Screenshot is from this address, and it shows two examples of timestamps screaming out loud:

• I have stolen 69 days! You will not catch me soon, and soon I will nibble on your personal time.
• Nice, I have stolen 269 days. Is there more to it?

@robert.frunzke I totally agree.

added Manage [DEPRECATED] and removed ~2278658 labels

@jeremy_ Something we should look into soon.

Please add an option that disables relative dates on the whole Internet ;)

One of the most annoying examples of overengineering one can find: makes it more difficult to know the exact date (which month? which day of week? which time of day?), to know which date is earlier or later ("4 days ago" vs "4 days ago"), rounding problems, does not work if you print the date or take a screenshot, ... so many issues that even having the option to hover over the date is not enough to fix the problem.

Also, putting critical information like this behind a hover effect disadvantages touchscreen users. The simple flick of the wrist envisioned by the user interface designer is replaced by an annoying double-tap.

added [deprecated] Accepting merge requests label

+1 for a user-level preference to display actual date/time stamps instead of relative time.

...and for Robert's point that relative times are great for apps that focus more on the "cute" but actual date/time stamps are for functional/productive environments.

mentioned in issue #56997 (closed)

mentioned in issue #57620 (closed)

mentioned in issue #57654 (closed)

mentioned in merge request !25381 (merged)

mentioned in issue felipe_artur/prod-personal-tests#8 (closed)

@akaemmerle While you seem to set milestone %GitLab Contribute 2019, what do you mean? Removing the milestone, but feel free to re-schedule this.

removed milestone

added popular proposal label

added devopsmanage label

This would be a nice to have.