Feature request: Display the exact date/time of each action in the list of worflow runs

[oksana-c]

Select Topic Area

Product Feedback

Body

The exact date/time of GitHub Action execution is shown on hover only.
The task of visually comparing timestamps of multiple actions is challenging when forensics must be performed quickly.

---

As a GitHub Actions user, I need to see the exact timestamp of when the action was run at a glance without having to hover over the relative time text, so that I quickly analyze the information.

---

[rgegriff]

👍 The current display is fine most of the time; but we use a LOT of actions, and not being able to see exact timestamps in the UI makes it fairly difficult to do forensics when things go wrong.

[mmustala]

Exactly. Right now I would need to know what was deployed to our server right before a certain timestamp.

[mmustala]

Hey, found out that when you hover the "3 weeks ago" it shows the accurate timestamp. So I can find the deploy I'm looking for.

[zacmoss-jaspar]

This would be GREAT.

[rjcoupe]

This is shocking in its absence. The UI happily shows you far less useful, yet presumably similarly sourced information like "4 days ago", but appears designed specifically to not show you an actual date and time.

[zacmoss-jaspar]

"4 days ago"

"Yeah but when exactly?"

"Dunno lol"

[jackofsometrade]

My thoughts exactly. It's really important to have precision in tools like this. The irony is that it requires more work to say "1 month ago" than it does to just provide the exact time. Why is this being hidden from us? It is important information.

[realugbun]

+1 to this request. I'm an Engineering Manager with about 50 devs at the company. We use Github actions for all our deployments and CI/CD. Having an entire month's worth of actions grouped into "last month" is very hard to work with. It's even worse that when you click on the action it still shows you "last month" instead of the date and time it was run.

[jan0991]

Simple chrome extension that solves the issue: https://github.com/jan0991/github-actions-full-datetime

[msorens]

Found one glitch that needs fixing, though: the extension frequently uses the wrong AM/PM designator. I posted that as an issue.

[BitSteve]

I've forked and improved it to show on all Github pages
https://github.com/BitSteve/github-full-datetime

[msorens]

Just tried it and (a) it works and (b) it fixes the AM/PM issue I noted above (by using 24-hour time 😉 ).
Thank you @BitSteve !! 🎉

[BitSteve]

LOL. My pleasure. I decided to use 24-hour time since it is shorter.
If I get a chance in the future, maybe make it configurable.

[wilblack]

I just installed this. Works great. Thanks.

[martinkoch-geniebelt]

+1 - I was just trying to figure out which release caused issues in production, and having the exact build time to compare against my logs would make my job a lot easier.

[daniel-lopez-puig]

If you hover the "x days/months/years ago" then you have exact time 😄

[martinkoch-geniebelt]

Thanks. I see it in the HTML if I inspect the source, but actually not on hover (chrome, 120.0.6099.71)

[martinkoch-geniebelt]

Well, actually ... now it appears on hover 🤷 :) - thank you.

[daniel-lopez-puig]

HOVER the mouse on the "x days/months/years ago" and you have it

I just put it here because if you google it just looking for the exact time and don't care about the feature and you are like me and read in diagonal .

[linucks]

The hover isn't working for me [Chrome Version 120.0.6099.234 (Official Build) (arm64)]. I can see a "datetime" and a "title" attribute that have the information, but nothing happens when I hover and when I activate hover in Developer Tools on any of the elements, nothing happens,

[amnuts]

The hover is a little annoying to do when you have a lot actions to go over.

The tag GitHub uses is documented at https://github.com/github/relative-time-element. So if you have a plugin that allows you to run arbitrary js on a page, then you can do something like:

document.getElementsByTagName('relative-time').forEach(node => {
    node.setAttribute('format', 'datetime');
    node.setAttribute('hour', 'numeric');
    node.setAttribute('minute', 'numeric');
    node.setAttribute('second', 'numeric');
})

and it'll change the format of the time to be more full.

But I really, really hope GitHub put in a toggle switch for this in the preferences!

[ttlns]

document.getElementsByTagName('relative-time').forEach(node => {
    node.setAttribute('format', 'datetime');
    node.setAttribute('hour', 'numeric');
    node.setAttribute('minute', 'numeric');
    node.setAttribute('second', 'numeric');
})

TypeError: document.getElementsByTagName(...).forEach is not a function

Refactored..

function show_full_time(){
  let s = document.getElementsByTagName('relative-time');
  for (let node of s){
      node.setAttribute('format', 'datetime');
      node.setAttribute('hour', 'numeric');
      node.setAttribute('minute', 'numeric');
      node.setAttribute('second', 'numeric');
  }
}
show_full_time()

[nghhoese]

Any update on this this would be really nice to have

[coactive-jeffrey]

We need exact timestamps for post-mortems. Please add a mouseover or something that gives us the exact time and timezone. The existing "Manually triggered last week" stuff isn't good enough to help us track and debug errors.

[larmitage-bjss]

As others have said, you can see this on hover, however it would be nice to be able to see it quicker and easier for skimming through pages of runs
I don't see why this can't be an option in your personal settings the same as timezone and (not sure github has this but other apps do) whether you want to see times in 24 or 12 hour clock

[kevin930321]

2024-04-26-12-40-31.online-video-cutter.com.mp4

When u use the mobile web mode, it'll show a glimpse when u reload it, really weird design.

[pfoneill]

+1 for this feature.

In addition it would be nice to have the current date/time exposed in a top-level variable that can be included in the run-name:
e.g.

name: nightly build
run-name: Nightly build on ${{ github.date }} at ${{ github.time }}

[msorens]

Bubbling this up because it solves the problem (as of today 2024.05.30 !!): https://github.com/orgs/community/discussions/58663#discussioncomment-9608722

In a nutshell, @BitSteve created a Chrome plugin that adds a full date/time next to the existing relative date/time.

[Xaeroxe]

GitHub please fix this. It's absurd that I have to install a browser extension just to get this basic info. I'm an engineer, I want precision from my tooling.

[onreal]

If you want to see the exact datetime an action was run, you can right-click on the Actions page and inspect the source. Look for the <relative-time> element that renders the “x days ago” text.

Personally, the relative time works well in most cases, but when I do need the exact timestamp, it's right there in the DOM.

That said, +1 to getting this fixed (assuming it's a bug), since the exact time is already sent to the client but just not displayed.

[qoomon]

I'm using the solution from above as a bookmarklet, works like charm.

javascript:(function (){  
    let s = document.getElementsByTagName('relative-time');
    for (let node of s){ 
        node.setAttribute('format', 'datetime');      
        node.setAttribute('hour', 'numeric');      
        node.setAttribute('minute', 'numeric');  
        node.setAttribute('time-zone-name', 'shortOffset');   
}})();

[ttlns]

My suggestion here: At least make it (especially the rounding) consistent. e.g.

Chrome extension: kaliiiiiiiiii/github-accurate-timedelta (Chrome webstore)

[timcosgrove]

The decision to show relative 'human time' has to have been made by a person who never actually has to manage CI/CD. There is no situation in working with CI/CD where 'last week' is a useful piece of information.

If you hover over the relative human time, you get the real time. Github is in fact using a web component called <relative-time> to wrap the real date & time.

I strongly suspect this was a UX decision made by someone who does not actually do this work. In most cases, relative 'human' time is in fact what you would want to see. CI/CD is not one of those cases.

At a very minimum, please give users the option to choose how the time is displayed.

[atkinsjb]

Celebrating 2+ years of users complaining about this issue with no update from Github. 🎉🎂🎉

What do you learn when users are so frustrated with your UX that they write their own browser extensions to fix it???

[lknhd]

i am f ing furious with this

[RomanMindlin]

Are there any estimates?

[rdhzl]

If there were it would be something like "In a Few Months", "Next Year", "Two Years From Now".

[4wk-]

@mikeplem that's not the place we want and need timestamps.
This thread is about the "All workflows" page, as shown is the original post https://github.com/orgs/community/discussions/58663#discussion-5323515

[mikeplem]

My mistake. I am going to delete my comments since it does not add value to this issue.

[Quezion]

Here in the middle of an incident alert, I can't believe GitHub is displaying "last week" on our last service prod run which was 10 days ago.

Please prioritize & fix this. Developers need precision, not to have their hands held with inaccurate human readable timestamps.

[geoidesic]

Please prioritise this!

[eshattow]

Also see ref.: https://github.com/orgs/community/discussions/41845

[brainwipe]

GitHub, I need to know the exact time and date when an action started. This vague nonsense makes it impossible. You've not given us this information after 2 years of complaints? Why not?

[jbeers]

Can this just be hotfixed with a tooltip that displays the exact date and time already?

[Nightblade]

Looks like they've implemented it.

[eshattow]

No, it shows "Last week" and other useless humanisms

[ttlns]

For kaliiiiiiiiii/esdtracker/actions , I can confirm (matching discussioncomment-14466846) the date to be shown in the following format:

1. Today at 2:55 AM for recent actions (guess: same day)
2. Sep 20, 2:47 AM GMT+2

Important question now is, based on what Timezone it counts as "recent", e.g. same day.

An improvement, yes. But not a complete fix 🥲

[zaataylor]

👋 Hi there @kaliiiiiiiiii! Regarding:

Important question now is, based on what Timezone it counts as "recent", e.g. same day.

Here's how it currently works since last Thursday's (September 18th) GA:

• For runs which are less than an hour old, we use the existing relative time display.
• For runs older than an hour, but which occurred on the same day, we use the Today at hh:mm format you listed in your example above.
• For runs older than that, i.e. not on the same day, we use the absolute time including the day, month, (year if the run was last year) and timezone.

An improvement, yes. But not a complete fix 🥲

I agree! All I can say is, we're working on it, and I'm sorry this isn't ideal right now! 😄 We chose the 1 hour threshold and "semi-relative", Today at hh:mm time display initially because seeing the exact time as soon as the run started felt a bit awkward from a UX perspective. Ideally, this would probably take the form of something like a toggle-able user setting, but it's not there yet, and we're aware of that.

There are a group of us advocating internally for prioritizing and fixing these kinds of papercuts/product gaps that users like those in this discussion thread run into. I implemented these changes along with a colleague based on this discussion, as I had time, aside from my normal, day-to-day tasks. It gives me immense joy to make small improvements that make things work better for our users, but these changes unfortunately don't happen as fast as you (or I 😄) would like! We welcome constructive feedback on how we can make this better, and we have further ideas/discussion for using this or a similar display format in other high-trafficked UIs.

[zaataylor]

👋 😄

Last Thursday (September 18th), we released a change to improve how the date/time is being represented in Actions workflow executions.

Previously, the exact date/time of a GitHub Action execution was only visible on hover as you all have described in this thread (see the screenshot below, which was pulled from the original discussion comment here), making it harder to quickly reference when a run occurred.

Now, we've introduced a 1 hour threshold before transitioning from relative to absolute time to improve clarity and efficiency for anyone tracking workflow runs. To strike a good balance between providing enough information for a user to correlate changes in their system over the course of the same day with an exact hh:mm time, we did the following:

• For the first hour, you'll still see the relative time e.g. 30 minutes ago
• After that hour has elapsed, you'll see a semi-relative time e.g. Today at 8:33 AM
• Finally, for runs older than the current day, you'll see exact time e.g. Sep 16, 10:29 AM EDT

Feel free to leave a comment in this thread with any thoughts or feedback! I worked on this with a colleague alongside my normal, day-to-day work, and we do have ideas for how to improve this, and we welcome continued, constructive feedback. I know the preexisting time display behavior is annoying and makes the experiences of tracking workflow runs unideal (to say the least). We are working to improve it!

[kevinhpage]

Thanks so much for your work on this!

[eshattow]

• For the first hour, you'll still see the relative time e.g. 30 minutes ago

Does the pop-over show the exact time?

• After that hour has elapsed, you'll see a semi-relative time e.g. Today at 8:33 AM

Does the pop-over show the relative time?

• Finally, for runs older than the current day, you'll see exact time e.g. Sep 16, 10:29 AM EDT

Suggest to tri-state relative mode somehow, and an actionable UX feature for selecting a different relative time reference. Weak on the details how this could be implemented in UX but it would make the relative time a useful functional feature. Often when we are saying this relative time feature is annoying what we mean is that it is an obstacle when what we are likely trying to do is solve a problem that uses a different time reference than "now".

Example: Single-click a UI element (for example any of the calendar glyphs but not the text) anywhere on the viewed page to tri-state this for the whole page being viewed:

• Blended
• Relative
• Exact

Search method from UI (clicking calendar icon is perhaps better suited to this; caveat):

• Relative time relative reference
  • Relative to "now"
  • Relative to calendar date selection (defaults to "now" or selected commit context and shows additional reference text "+/-" and the selected date or commit id)
  • Relative to commit

Future preferences:

• Blended time demarcation select how much time elapsed between display of relative and exact time
  • numeric combo box or slider UI input 1-9999
  • unit selection
    • minutes
    • hours
    • days
    • months

[Nightblade]

Is there a public-facing change-log for this kind of thing?