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).
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.
+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.
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.
Mark Fletcherchanged 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"
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"
@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.
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.
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?
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.
+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.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks.
As part of this migration, issues will be moved to the current
gitlab-ee project. We are starting with moving issues that have
been created at least a year ago, and are not part of the current
milestone.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
You can also find more information here:
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?