Option to show absolute dates

[josefdlange]

When investigating history, sometimes exact dates are more useful than "2 mo ago" -- would it be possible to have a toggle for this?

[Booligoosh]

B being able to tap on the "2mo ago" to see the full date/time stamp displayed would work rather than (or in addition to) a global toggle

[FelixHerrmann]

That's already there 🤔

[Booligoosh]

Neither tapping nor long tapping work for me — I'm on Android, so maybe it's a difference between the iOS and Android versions? Also, my main use case is tapping on the relative dates for commits rather than discussion posts, any idea if that tooltip works for commit dates too on iOS?

[FelixHerrmann]

Yes, this menu/tooltip is on every relative date label (including commits). It seems like this functionality is just not there on Android, maybe you should create a dedicated feature request for that (feel free to use my screenshot).

[taki-on]

Thank you for your suggestion! We will track this issue internally :)

[lilydjwg]

I find it bothersome translating the Month names personally. (telling AM / PM also...)

I do want month names to be translated, because I easily think Oct is the eighth month and Dec the tenth and so on.

AM / PM is locale-dependent: locales using 12-hour scheme have them; locales using 24-hour scheme don't. Translating according to locale will solve it (e.g. using the browser's Intl.DateTimeFormat.

[ket395]

I think there is also another important issue translating from English to English like languages works fine, hell some users won't even mind. But the same isn't true for languages that don't even use the same script.

And languages that are formed by beautiful letters and are perfect for practicing and honing calligraphy like Arabic and Japanese are really ill suited for automatic programmatic translation as demonstrated by the Chinese example above, because of the poor UX of Unicode spec in real world use cases in software GUIs and CLIs. Nothing can be done for that anytime soon.

Also I still don't see the time for a issue creation or a comment. Hovering is not the best UX because that blocks the mouse or trackpad usage. Click or tap or gestures are a significantly better UX. Now I better trademark this, and get patents like Google. 🤣

see ths for confirmation of my frustrations being universal - by maddes-b
Maddes https://github.com/orgs/community/discussions/5972#discussioncomment-4160739

Manish
Check out my kind of oldfangled, kinda newfangled, kinda cool, inevitably thought-provoking profile.

[planetrocky]

@taki-on any updates please?

[HansHighness]

Year>Month>Day>Hour>Minute>Second Logical and easy to understand.
2025-09-21 17:55:03

[maddes-b]

+1 for making this an option.

"1h ago" is not precise (can be anything from 60 to 119 minutes ago), and I don't like "1 months ago" or older.
The web page should just give coders/admins all detail information at a glance, so they can work without hassle.
Hovering over each timestamp is time consuming, therefore annoying, and has to be repeated several times to get an overview and/or compare.
Using UTC as default timezone would be fine for coders/admins, and newbies can easily learn what's their delta to UTC is via Wikipedia or www.timeanddate.com.

Workaround:
I installed Tampermonkey (a Greasemonkey alternative) on Firefox for UserScripts and then the UserScript GitHub-static-time. That works well.
I am using the following format Y-MM-DD HH:mm:ss z (see moment.js formats), no UTC yet. Thanks to refined-github for hinting me to this.

Still the option to show absolute dates should be a GitHub standard feature.

[mering]

Hovering is not even possible with touch input like phones.

[mering]

Rephrasing, there is no way to view the full date on the major smartphones with the major browsers (99%+ market share).

[ket395]

I wish people with the same PITAs with Github like me would sign off with their Github readmes. It's there for a reason. Use it well. Use it often. Ain't nobody got time to hover on your profile to read 50 chars or whatever is cramped in one line.

Nice to meet you all.
Manish https://github.com/ket395
Check out my kind of oldfangled, kinda newfangled, kinda cool, inevitably thought-provoking profile.

[s40623]

有在

[janeklb]

A keyboard shortcut to toggle absolute time vs relative time would be fantastic

[RobertKrawitz]

UTC and accuracy to seconds would be best by far for absolute dates. There's no localization issue with UTC dates, and we might as well do it correctly.

[matrixik]

If someone is fine with ISO datetime format that will appear after focusing on relative date I made simplest possible user script:

https://gist.github.com/matrixik/7bb0d7a290c66e6de29d183c4a38424d

[mnurgpi]

I have a bookmarklet based on your code - it replaces the parent element instead and maintains the link to the committer.

javascript: (function () {
  const rts = document.querySelectorAll("relative-time");
  rts.forEach((rt) => {
    const parentElement = rt.parentElement;
    if (parentElement) {
      const a = parentElement.querySelectorAll("a");
      if (a[1]) {
        const href = a[1];
        parentElement.innerHTML = "";
        href.style.marginRight = "5px";
        parentElement.append(href, rt.title);
      }
    }
  });
})();

Before

After

Hi,
It does not work for me.
I modified to this and it works for me:

javascript: (function(){
 const rts=document.querySelectorAll("relative-time");
 rts.forEach((rt)=>{
  const parentElement = rt.parentElement;
  if(parentElement){
   const a=parentElement.querySelectorAll("relative-time");
   if(a[0]){
    const reltime=a[0];
    parentElement.innerHTML="";
    reltime.style.marginRight="5px";
    parentElement.append(reltime, rt.datetime);
   }
  }
 });
})();

[GfEW]

@MasterInQuestion
I've tested your snippet with various pages throughout github in Cromite for Android using the Home Page workaround. So far, it works perfectly for me - thank you!

This might be the best we can get, short of github actually offering a proper user option.

[diegobmi]

How to Easily Toggle Absolute Dates on GitHub Using a Logitech Device (No Extensions Needed!)

If you use a Logitech mouse or keyboard compatible with Logi Options or Logi Options+ (such as MX Master mice, MX Keys keyboards, etc.), you can automate running the bookmarklet to show absolute dates on GitHub—no browser extensions required!

Steps

1. Add the Bookmarklet:
   • Create a new bookmarklet on your bookmarks bar with @mnurgpi code (THANK YOU!!!):

     javascript:(function(){document.querySelectorAll("relative-time").forEach(function(el){if(!el.shadowRoot)return;el.format="datetime";el.hour="numeric";el.minute="2-digit";el.second="2-digit";});})();

   • Place it as the first bookmark (the first to the left) on your bookmarks bar. You can save it wihtout name to save space or even with an emoji as its name:

2. Create a Smart Action in Logi Options/Options+:
   • Add these steps in order:
     1. Ctrl+Shift+B (Show bookmarks bar in Chrome)
     2. Alt+Shift+B (Focus the bookmarks bar)
     3. Right Arrow (Navigate to the first bookmark)
     4. Enter (Run the bookmarklet)
     5. Ctrl+Shift+B (Hide the bookmarks bar again)

No specific delay needed between keystrokes or steps. As of today Logi Options default/minimum delay is fixed to 0.021 s, so it is quite fast.

• Save it and name it something like GH_absolute_dates.

3. Assign the Smart Action to your preferred mouse button or keyboard key.

In some cases you can even assign the button to that smart action only when the active app is your browser.

4. Usage:

   • On any GitHub page, press your programmed button or key and enjoy absolute date/time display instantly!

5. Result:

Note:

• Adjust the number and direction of Arrow presses if the bookmarklet's position changes. I went with putting it in the first position so new bookmarks will be added to the right
• This method does not require any browser extension or extra permissions.
• Works with any Logitech device supported by Logi Options/Options+.
• I guess it depends on writing direction or Chrome GUI specifics

Hope that helps anyone!

[tinu1976ch]

javascript: (function(){
 const rts=document.querySelectorAll("relative-time");
 rts.forEach((rt)=>{
  const parentElement = rt.parentElement;
  if(parentElement){
   const a=parentElement.querySelectorAll("relative-time");
   if(a[0]){
    const reltime=a[0];
    parentElement.innerHTML="";
    reltime.style.marginRight="5px";
    parentElement.append(reltime, rt.datetime);
   }
  }
 });
})();

@mnurgpi
how to change that for this?

<div class="committer gl-text-sm">
verfasst von <a class="commit-author-link js-user-link" data-user-id="8" href="/xxx">yyy zzz</a> 
<time class="js-timeago" title="13. Oktober 2025 um 13:35:07 MESZ" datetime="2025-10-13T11:35:07Z" tabindex="0" aria-label="Okt 13, 2025 11:35vormittags" data-toggle="tooltip" data-placement="bottom" data-container="body">vor 4 Stunden</time>
</div>

thanks for your help

[YCJDWCJI]

[RobertKrawitz]

So much better, especially when setting it to 24 hour time.

All too many sites insist on using this "friendly" time. The problem is that speaking casually is not the same as reading something that may be out of date, and precision sometimes is necessary (particularly on this kind of site).

[RobertKrawitz]

I really appreciate the work you're doing on this, but it needs to be fixed on the server side. People who want to look at Github from mobile devices are out of luck, since mobile browsers don't support (at very best) a full range of addons. I simply don't understand the insistence on using relative or "friendly" times for this -- could someone from Github please jump in and explain this design decision?

[GfEW]

I consider such general purpose content filter a vital part of browser core:     Fixing things on the user side appears very frequent.

That's another kettle of fish, but I'd consider tremendously helpful if browsers could be made to stick with the user's preferred time zone and format reliably, and those choices would include UTC and ISO formats, respectively. It's a shame such a basic concept has gone down the "we know better what you want" chute.

That being said, it's neither relevant to this issue nor very likely to make it disappear.

[lilydjwg]

Not only absolute dates for distant timestamps is needed, but it's also essential for near ones too. How do you compare "yesterday" with another event happened at "2024-05-08 10:42:58"? Hovering works for one timestamp at a time. It's laborious to hover on and read a couple of them.

[RobertKrawitz]

Not to mention useless if one wants to take a screenshot, both in terms of not being able to see all of the timestamps and because relative dates are inherently useless for something whose lifetime extends beyond the moment.

[gpi-eaglys]

Same thing with screenshots. How the hell can I make a point with a screenshot saying "Yesterday"?

[jbauerrfid]

Just use ISO 8601 formatted timestamps in the form of "YYYY-MM-DD'T'hh:mm:ss.millis" + timezone offset

like "2025-02-06T11:30.000+01:00"

These are still easy to read, but also precise, and all modern programming languages can parse them.

See also https://en.wikipedia.org/wiki/ISO_8601

[jamesgeddes]

We are 2.6 years later and there is still no native option to display absolute datetimes. This surprises me, as it must have taken engineering effort to provide relative datetimes; the norm for most of the life of the Internet has been to show absolute datetimes.

Why, then, is it so hard to give users the choice?

The best solution that I have found so far is "Nudiflorum: display absolute date on GitHub" (repo) for Firefox. This works out of the box. That said, this is a workaround for something that should have been the default all along.

[gpi-eaglys]

it must have taken engineering effort to provide relative datetimes

Exactly because it took so much effort, it must be used every time, everywhere. (sarcasm)

[tdowg1]

We are 2.6 years later and there is still no native option to display absolute datetimes. This surprises me, as it must have taken engineering effort to provide relative datetimes; the norm for most of the life of the Internet has been to show absolute datetimes.

Totally agree.

We are now 3.25 years later. Look at what people are having to do in order to get precise date and time. Each and every one of us are having to resort to bookhackmarklets or 1-off browser extensions or a Greasemonkey equivalent tool(or even NONE of these because they are on mobile), simply to get precise timestamps(or NOT) of important events herein. Whereas 1 person could make this change, server-side. Actually, a crew of 0 people could allegedly make this change happen(continue reading, to find out what I mean(huehuehue...))

At this rate, we will need to start considering how much longer these client-side hacks will continue to work before half our web browsers decide to modify or remove some obscure function call that our hacks rely on. Or even less likely(sarcasm), github modifies an element id...

PLEASE FIX YOUR SITE, MICROSOFT GITHUB. THIS IS BASIC WEB DEVELOPMENT. Actually, why can't CoPilot fix your datetime website bug for you? I thought that was the big new magic now.

[RobertKrawitz]

It would be a lot simpler (and to me, at least) a lot easier to read to only have the absolute date/time. UTC would be fine, and would avoid ambiguity in the corner case of the transition hour from daylight saving time to standard time.

(I actually did run across an issue with this, although in that case it was the "missing" hour in the transition from standard time to daylight saving time. I got assigned a bug somebody had reported in KPhotoAlbum, involving certain photos that were failing to load correctly. I couldn't reproduce it, but when I looked carefully at the timestamp in the EXIF data, the photos in question were taken during that ghost hour, and the camera did not record summer time, as the EXIF spec at the time did not support that. Qt bombed out when trying to convert that kind of forbidden date. So I respect the issue of corner cases with dates and times, but UTC avoids all of that. Even leap seconds are properly handled in UTC.)

[Loveco255]

Thank you for your suggestion! We will track this issue internally :)

[RobertKrawitz]

That's exactly the same response you gave on 10/14/2021, 05:13:38.

[okadots]

+1 Agree with @GaryReckard that you could put the setting under "Appearance"

IMO default should be absolute timestamp with the option to use "time ago" format.

[shyazusa]

+1

13 hours ago

Even when viewed in the morning, it's not intuitively clear what time the post was made.

[TFWol]

Much like their surveys, it feels like Microsoft doesn't really care all that much.
Most of their actions seem to primarily serve as window dressing

There are so many quality of life posts like this that end up being ignored for years, if not indefinitely.

While there are workarounds for browsers (userscripts, bookmarklets, etc.), you're pretty much out of luck using their official app.

[diegobmi]

Allow users to display and/or easily copy absolute/exact dates in the GitHub UI (e.g., workflow runs, commits)

Proposed Solution:

Add a user or organization setting to toggle between relative and absolute date/time formats throughout the GitHub UI.
Provide an option to easily copy the full absolute date/time value, either through a context menu, copy button, or by making the tooltip text selectable.
Allow customization of date/time formats (e.g., YYYY-MM-DD HH:MM, ISO 8601, locale-based).

Why is this important?:

Improves accessibility and usability for users needing precise records or logs.
Essential for compliance, auditing, and reproducibility in CI/CD workflows.
Increases productivity for users who often need to copy exact timestamps for communication or documentation.

Steps to Reproduce (Current Behavior):

Go to a workflow run, commit, issue, or comment.
Observe that the date/time is displayed in a relative format.
Hover to see the absolute date/time in a tooltip, but the value cannot be easily copied.

Expected Behavior:

Users should be able to configure the UI to show absolute dates/times by default.
Users should be able to easily copy the exact date/time value.

Additional context:

Many users have requested this in discussions and forums. Competing platforms often provide more flexible date/time display and copy options.
4 years have passed already @taki-on

[dominikj-cf]

This is 100% necessary!

How can I correlate regressions, metrics efficiently? (workflows, PRs)

Older entries even fallback to absolutely unprecise measurements like 3 weeks or last month.
Then, suddenly >1 month ago, you get absolute dates! (so you already have this functionality)

Just provide a simple toggle or shortcut!

Please 🙏

[maxammann]

A quick hack is to disable JS on the page.

[paolonevis]

+1 , I like the exact time

[gaelenm]

+1, exact time is very helpful in many situations, and especially being able to copy the date/time would be helpful

[planetrocky]

Has this been added? It's critical IMHO.

It's only 4 years old request.

[maddes-b]

@JackNWhite Where is this screenshot from? I cannot find this in my GitHub account on the GitHub web site, I only have Settings.

[JackNWhite]

@JackNWhite Where is this screenshot from? I cannot find this in my GitHub account on the GitHub web site, I only have Settings.

I apologise, I must have been asleep this morning. I was searching for the same thing for Gitlab.

[jamesmurdza]

+1

[coccoinomane]

+1

[bartbrinkman]

+1, must-have imo

[andrewdoyle19]

+1 to this!

[linesthatinterlace]

+1, please!