Use Standard Date/Time stamp and Commit ID for GUI

[kahopkin]

The feature request

I love the History, but what is very useless in the gui is how the History of anything is presented. Currently they are using the "Friendly" date format, which is vague and ambiguous, ie: "yesterday, few minutes ago, 2hours ago".
This is for both GitHub Desktop and also for the web application.
Additionally, in the Desktop, it would be great if we could also see the Commit ID in the list view. It would be an additional bonus if we could maybe see the parent commits links

In order to see the time I made the commit/change, I have to try to find the "sweet spot" for where to hover over (the whole list item is not triggering the hover...)

When something goes wrong, we (developers) usually have a pretty good idea on the time we made a particular change, and if we do commit frequently, in order to find the right history to revert to: we literally have to go through a lot of list items that will have the identical friendly date.
If I could see the actual time stamp, it would drastically cut down on how many items I need to review to find the right item.

Proposed solution

Instead of using the friendly date format, either make it customizable where the user could set a preference for date format, or just change the friendly date format to Standard date format.
I would love it if I could choose to see any date related data in the GUI in this format: (in BLACK font and NOT some light color font that barely separates from the background...)
05/10/2022 22:44:17
Can you please consider making this change or add a settings where we could choose date format?
I think tons of us, end-users would really appreciate some ability to customize the interface to what works for us.

Additional context

No response

[a2937]

I don't personally wanna add the commit id of the parent to the entry. But I do at least wanna add the commit id right next to the date time. And unfortunately the friendly datetime is super helpful for me.

[rtapella]

I'd also like the actual time because the "friendly" datetime is not useful when cross-comparing to other systems.

[rtapella]

I didn't even realize you could mouseover the relative date to show a full stamp. I'd still prefer to see it all in the list to cross-compare to lists of time stamps.

[steveward]

Requested in #17702.

[mattlogic]

I too would much rather see actual date/time for commits and actions. The current "friendly" format is too vague for comparing with other git clients, logs or file timestamps. "6 months ago" is OK if you just want a rough idea of when something was done, but is practically useless if you need to know whether a particular commit was done before/after something else.

The format for the actual date/time should preferably be selectable from a few common styles, or possibly based on the user's locale. The mouse-over date tooltips are currently US-style like "Dec 8, 2023 5:16 PM GMT" but at least that's unambiguous and readable. Other formats would be YYYY-MM-DD or DD-MMM-YYYY and 24-hour time.

[gjsmith66]

Not showing actual date/time makes no sense. I have no other tools/apps that I use that default to this view. At least give an option. Thanks!

[aterbo]

I would love to see this option, too, both on web and desktop. I don't know why this was closed. I'm trying to determine what happened when in my code base, and looking at dozens of commits that all say "committed 2 months ago" is useless.

Is there an open issue for this? This issue was closed with no apparent resolution, and the other associated issue #17702 was closed because they were referred to this issue.

[cfrupp]

I don't personally wanna add the commit id of the parent to the entry. But I do at least wanna add the commit id right next to the date time. And unfortunately the friendly datetime is super helpful for me.

In Desktop, it should be configurable by the user: "friendly" or exact, whatever floats your boat.

[cfrupp]

The mouse-over is OK, but it's really clumsy if there are a whole lot of commits displayed as "3 days ago". Then you have to mouse around and hover over each one in turn. It would be more efficient if you could see them all at a glance.

[SRNissen]

I would love to add my voice to the chorus clamoring for accurate timestamps.

I would add that "no timestamp at all" is a better option than "friendly timestamp" given the frequency of erroneous friendly timestamps as soon as you're more than an hour back, though possibly that should be a separate issue.

[SRNissen]

C.f. issue #18009 which records a UX bug caused by """friendly""" time stamps.

[steveward]

From #18136:

I find that i nearly always hover over the "X days ago" to get the timestamp for a commit. This is pretty key IMO for a fast moving team that makes multiple commits per day. For example, a deploy may be triggered by a commit, and i'd like to be able to quickly match up exactly which of today's deploys were caused by which commit, or quickly scan for which commits happened before/after a particular deploy.

[hdhalter]

I would also prefer to see the actual date. And now I can't even see the actual date when I hover over the relative date and it's driving me crazy! I have to manually count back on my wall calendar or guess the actual date. Any tips on how I can get this ability back?

[steveward]

@hdhalter I'm not seeing any issues with hovering over dates on macOS and GitHub Desktop v3.3.9. What version of GitHub Desktop and operating system are you using?

[hdhalter]

Hi @steveward - I use a browser, not Desktop, and my mac version is Sonoma 14.3 (23D56). I'm being asked to update to Sonoma 14.3.1 so as soon as I reboot, I'll get the update. Perhaps that will fix it? In the meantime, I see specific dates on some of the comments this issue. So much more helpful!

[steveward]

@hdhalter this issue tracker is specifically for GitHub Desktop, if you're having issues with github.com you'll want to reach out to GitHub Support.

[steveward]

Requested in #18273.

[thewhistler1]

Yes, please show actual date.

[SRNissen]

This issue is for the desktop client

[subfuzion]

@SRNissen Oops, my bad -- too many tabs open following related threads! Thank you!

[trusovn]

I'd also would much rather see the dates. I need to perform cherry-picking from lots of other commits and being able to see the dates would simplify the task.

[steveward]

Requested in #18959.

[johnmgithub]

Seems odd that people asking for more than four years for something that is user-hostile to be changed is met with complete indifference.

[aterbo]

Seems odd that people asking for more than four years for something that is user-hostile to be changed is met with complete indifference.

@johnmgithub At this point I don't expect this to actually be resolved, but I'm still subscribed to notifications on this thread for morbid curiosity as to why it is somehow seen as a controversial request.

I haven't seen a single outside user of these products show opposition to making this a changeable setting. I definitely haven't seen someone clearly state a preference for the current UI display!

[cfrupp]

I haven't seen any justification for NOT making this change. On the other hand, I don't have the patience to read through a 4-year history. Does ANYONE have ANY idea why Microsoft has not implemented this request?

[jartf]

Does ANYONE have ANY idea why Microsoft has not implemented this request?

@cfrupp From #9147:

this has been a longstanding GitHub convention

read: "it works so don't fix it", and

We haven't heard from many people and that the specific date is a super important piece of information

Basically they're saying there's no popular demand. This issue is proving otherwise though, so someone might wanna look into it.

[cfrupp]

So let me get this straight. GitHub is the world's premier change management system, and the GitHub team is afraid of change? Just sayin'.

[chriswm]

Basically they're saying there's no popular demand. This issue is proving otherwise though, so someone might wanna look into it.

How do I add my vote of support for getting this obtuse date format fixed?

I need to check the specific date and time the PR was merged. That should be a 2 second effort, and this lack of precise date is turning a 2 second effort into a 20 minute effort.

[Jamie-Landeg-Jones]

I need to check the specific date and time the PR was merged. That should be a 2 second effort, and this lack of precise date is turning a 2 second effort into a 20 minute effort.

I just found out (from earlier in this thread) that when you hover over the date, the absolute date is shown.

It's a pain to use properly, but it may help you in some cases.

[Jamie-Landeg-Jones]

I remember when forums started using this "bling" date format. I think it was a JS script made available to look cool.

I hated it then, but never thought a site like github would pop up with the same imprecise format. Yet, here we are, and here we STILL are.

It's added code to make things worse.

[winzig]

(I've been creating forum software for 30 years.) The relative date format is not unique to JS, and the benefit of it is that it's easier for humans to read no matter which timezone they're reading from, or which timezone it was posted in.

However, while it works well in forums and social media posts, IMO it's a bad choice for precise work like a Git history. At the very least, if it were me, I'd give people a choice (absolute/relative), and I would have it switch from relative to absolute date format when the amount of time being represented is more than a day. "5 min ago" and "2 hrs ago" seems fine, but when I scroll down and see "2 months ago" on different commits that happened days apart, it falls apart...

[chriswm]

I just found out (from earlier in this thread) that when you hover over the date, the absolute date is shown.

It's a pain to use properly, but it may help you in some cases.

I eventually stumbled upon this too. It's not available in all places where the time is shown though, and the first couple places I tried to hover / click on didn't display the absolute date, so I stopped trying even though if I had tried it on the other places it would have worked... which I eventually discovered by accident.

Thanks for the tip!

[steveward]

Requested in #19154:

Currently GitHub Desktop will helpfully show "2 months ago" for example, and if you hover your mouse over you'll see the full date. However, there's cases where I always want to see the full date in the user interface. Hovering my mouse over the dates just slows things down.

[jclark-dot-org]

A big use case for git in general and github desktop in particular is being able to find a specific change to the code base; Github Desktop is great for scanning a list of commits and quickly looking at the details.

A use case that happens frequently for me is trying to quickly find a commit based on a specific date or time range. I often have clients ask about a specific change from months ago; I can quickly find the date by searching email or issue-tracker tickets. Many clients know the dates where changes were tested or went live. But in an active repo, knowing you are looking for a commit from June 13 means scanning everything that says "2 months ago" or "3 months ago", because today is Aug 28 and I don't know if that's considered 2 or 3 months. There might be several dozen commits over those two months.

But my human eyes can spot 2024-06-13 (or 6/13/2024, or Jun 13, 2024) out of sorted list of dates almost instantly.

[jessetan]

For the GitHub website there are three Chrome extensions that change the datetime display to be absolute:

• https://chromewebstore.google.com/detail/github-exact-dates/kjhknbbgbadlogbdfffgmngdgclomfol - https://github.com/kubilayeldemir/github-exact-dates
• https://chromewebstore.google.com/detail/github-exact-time/fanolkboeldmhkpeaanhhkogoeenbgko
• https://chromewebstore.google.com/detail/github-absolute-dates/iepecohjelcmdnahbddleblfphbaheno - https://github.com/egyptianbman/chrome-github-absolute-dates

[Jamie-Landeg-Jones]

Thanks for that. Unfortunately, I could only get one to work, and it only works on the commit list not the tree browsing.

The fact that people wrote this extension in the first place speaks volumes, yet no-one is listening.

[Steve-Aze]

This ticket is two years old, lots of people are asking for it, and it is still not planned. The issue that people are really clamouring for (see also all the tickets that have been merged into this and therefore closed) is to change '29 days ago', 'last month', '7 months ago' etc into something more meaningful, i.e. the actual commit date and time. This of its own would seem to be not too hard a thing to achieve.

It's sub-optimal then that it got rolled-up into a multi-issue ticket with things that are harder to achieve and less in demand. I'd like to suggest that we split this ticket out into multiple single-issue tickets, and then we can think about prioritising the commit-date issue without having to implement the other issues also, which are less in demand, harder to implement, and not universally favoured. With one issue per ticket, each issue can be considered on its own merits. Hopefully the meaningful commit date request would then come to the top of the to-do list.

[nielsduelund]

+1 from me.
You have the actual date in the HTML, so it can be displayed when hovering.
Why not add a setting, so the user (un)friendly can be replaced with proper date and time.
It will not require just that, because changing format for the date and time should be added as well - IMHO.
It must however be a minor change compared to the wast possibilities availablen and the complicated merging algoritms etc.
/niels

[drstevens]

Apologies for the additional comment here, but I've put up with these "friendly" timestamps since 2010 and have finally worked up enough frustration to look for an official solution.

I never want the relatively "friendly" time/date displayed. It's hard for me to imagine anyone would prefer "yesterday" instead of an actual timestamp, but I do understand that some people do. It seems like a user setting is necessary.

The hover behavior mostly works, but sometimes you just want to copy/paste the timestamp into something else, like a Grafana dashboard or JIRA issue. This is difficult/impossible with the hover workaround.

I know there are workarounds, like tampermonkey or bookmarkets, but really we shouldn't need to look for third-party workarounds that could potentially increase supply-chain attack surface area.

[aterbo]

@drstevens I don't think you should feel the need to apologies for the comment, especially a relevant and clearly thought out one. Multiple times this and other similar issues were closed due to apparent lack of interest or demand from users. I think the fact that comments on these issues just keep stacking up is the only way that demand is shown...

[pablott]

I also think this is an issue. And is not just in the history, but also in the commit view.
This does not really tell me much...

Currently even hovering in such situation shows the actual date, so that seems to be broken or removed.

[jeffchensonos]

Any developer or PM here? I hate to push you, but it's my nightmare the history doesn't show exact date!

[jeffchensonos]

@sergiou87 Could you take a look at this? I don't know who is in charge of this request or who will care about this request, but I hope someone can address this. Thank you.

[HughWarrington]

It's sub-optimal then that it got rolled-up into a multi-issue ticket with things that are harder to achieve and less in demand. I'd like to suggest that we split this ticket out into multiple single-issue tickets, and then we can think about prioritising the commit-date issue without having to implement the other issues also, which are less in demand, harder to implement, and not universally favoured. With one issue per ticket, each issue can be considered on its own merits. Hopefully the meaningful commit date request would then come to the top of the to-do list.

I absolutely agree.

Any of #5395, #9147, #17456, #17690, #17702, #17828, #17976, #18136, #18273, #18442, #18443, #18959, #19154, #19469, #19549 would do.

I'm not sure why those short and specific tickets have been closed in favour of this one, which is ill-defined and mixes several changes.

[cfrupp]

Heck yeah. Lumping all the issues together is counterproductive. There's this new idea, anybody heard of it? Agile development?