GitHub Community
Option to show absolute dates #5972
-
|
When investigating history, sometimes exact dates are more useful than "2 mo ago" -- would it be possible to have a toggle for this? |
Beta Was this translation helpful? Give feedback.
Replies: 21 comments 38 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
That's already there 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your suggestion! We will track this issue internally :) |
Beta Was this translation helpful? Give feedback.
-
|
Are there any news to this? I think that 30 months in, it's rather sad to see the efforts (below, as well as in various related discussions) put into post-market fix attempts rather than a real solution to the problem introduced by meant-to-be-friendly timestamps - and that's likely just the tip of the iceberg of everyday users who have to somehow deal with those absurdly vague timestamps on their own. The notion the general lack of exact time presentation could be reasonably remedied on a case-by-case "hover for a tooltip" basis seems misled, not just on mobile where hovering is unavailable, but also on desktop. Hovering every single (not-so) friendly timestamp in order to get a glimpse at a fraction of what you'd wish to be visible everywhere anyway is just cumbersome. If you cannot see more than one real timestamp at a time, understanding the whole picture, including temporal relations, is needlessly difficult. The one, basic solution to this would still be a user option. |
Beta Was this translation helpful? Give feedback.
-
|
Relative timestamps are the bane of my existence on any time-based entities, be they comments, commits, stories, forums, or anything else I haven't thought of. Aside from making date arithmetic very difficult, I have a lot of tabs open for a very long time, and a relative time that's days or months out of date is useless. I don't know what the motivation was for this in the first place, but whatever it is, it's categorically always wrong for me. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, the not-so-friendly timestamps are actually deficient (by design) in three ways: 1. Expressive granularity 2. Reference time 3. Time of "now" To be clear, I don't think there's anything wrong with the concept of "friendly" times. They are popular not just due to certain in vogue UX assumptions and design paradigms, but also because they obviously make sense for many who are more comfortable with implicit, fuzzy context than with explicit, accurate information. However, there are horses for courses. |
Beta Was this translation helpful? Give feedback.
-
|
@taki-on Any update after 3 years about making this display "feature" optional? Btw "3 years" is a "user-friendly" date. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
+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. Workaround: Still the option to show absolute dates should be a GitHub standard feature.
|
Beta Was this translation helpful? Give feedback.
-
|
A keyboard shortcut to toggle absolute time vs relative time would be fantastic |
Beta Was this translation helpful? Give feedback.
-
|
Global option, not only for Mobile. The need has been further instigated by the recent (probably not much recent) introduction of the even more "friendly" timestamps: whose unfriendliness rendered the issue urgent. Replace / enhance "x ago" by actual timestamp Replace "Friendly Date" format in favor of Date/TimeStamp Use Standard Date/Time stamp and Commit ID for GUI Option to always display commit date and time in History list |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. The real issue is to always see absolute dates without having to focus on anything. Being "friendly", i. e. colloquial, is exactly the wrong approach for something like this. If I send someone an email, and they later ask me when I sent it because they can't find it, I don't say "yesterday" or "last week"; I actually give them the date and time of the message translated into their timezone if I know it or otherwise UTC or appropriate canonical timezone. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Hi, 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);
}
}
});
})(); |
Beta Was this translation helpful? Give feedback.
-
|
The code seems like bad recursion whatsoever... I believe the effective part shall be: Added handling for "search" anomaly: Known issue: Potential enhancement: Further attached handling for file list compactness: |
Beta Was this translation helpful? Give feedback.
-
|
@MasterInQuestion This might be the best we can get, short of github actually offering a proper user option. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
See also: https://github.com/MasterInQuestion/talk/discussions/9 So sad that using a content filter to fix broken sites has become a frequent... ---- It appears "trusted-replace-node-text" in current release does not yet support referring the node's attributes in substitution pattern. Of course convincing the uBO developers to extend "trusted-replace-node-text" 's functionality may be a valid option... (potentially via "${datetime}" alike?) |
Beta Was this translation helpful? Give feedback.
-
|
uBlock Origin static filter ("My filters"): github.com$doc,frame,xhr,replace=/<relative-time\s.*?(?<![\w\-])datetime\s*?=\s*?(?:"([^"]*)"|'([^']*)').*?>.*?<\/relative-time\s*?>/<span datetime class="no-wrap">\$1\$2<\/span>/gsi
! github.com##span[datetime]:upward( .css-truncate ):style( overflow: visible !important; )
! ^ I'd probably recommend targeting ".css-truncate" directly...
! Per the recent shenanigan: https://github.com/orgs/community/discussions/139935#discussioncomment-10895208
github.com##:not( :matches-path(/^\/+[A-Z0-9](?:[A-Z0-9\-]{0,37}[A-Z0-9])?\/+[\w\-.]{1,100}\/+discussions\/+new\/+choose\/*(?=$|[?#])/i) ) .Truncate:remove-class("Truncate")
github.com##[class*="truncate"i], .TokenBase__StyledTokenBase-sc-47c3884c-0:style( overflow: visible !important; max-width: none !important; -webkit-line-clamp: initial !important; )
github.com##[data-testid="latest-commit-html"], span.css-truncate:style( word-break: break-word !important; white-space: normal !important; )
! github.com##span[datetime]:upward(1):style( width: auto !important; )
! ^ Likely obsolete.
! Somewhat quirky (to dynamic page loading):
! [ Below are mostly obsolete. ]
github.com##+js( trusted-replace-node-text, span, /^\s*?(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})(?:Z|([+\-])(\d{2}):(\d{2}))\s*?$/i, "$1$2$3_$4$5$6$7$8$9" )
! github.com##+js( trusted-replace-node-text, div[role="gridcell"] > span[datetime], /(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})(?:Z|([+\-])(\d{2}):(\d{2}))/i, "$1$2$3_$4$5$6$7$8$9" )
! ^ No support yet for selectors.
! Primarily intended to address space limitation of the file list.]] This replaces all such "<relative-time>" to "<span>" [1] with the "datetime" attribute as content. The RegEx parser is a shortcut that's not perfectly compliant (though strived to be) with standard XML/HTML implementation. [2] The "s" flag of RegEx requires Firefox 78+. [ https://caniuse.com/mdn-javascript_builtins_regexp_dotall ] For RegEx help: |
Beta Was this translation helpful? Give feedback.
-
|
I could further improve the custom filter into perfection (seamless indistinguishable from GitHub native): Note: |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
I consider such general purpose content filter a vital part of browser core: Many more notable things are notoriously wrong with mobile browsers. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Partly for such illy defined "Wed, 08 May 2024 10:42:58 +0000" non-sense could even receive wide adoption... People may have difficulty translating month names, spelt numerals alike; into their standard numeric form. E.g. Numeral: It also appears that big numbers tend to be unpronounceable: |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Exactly because it took so much effort, it must be used every time, everywhere. (sarcasm) |
Beta Was this translation helpful? Give feedback.
-
|
During my analysis: Proposal: E.g. [ [1] Even limiting the context for Western usage only. |
Beta Was this translation helpful? Give feedback.
-
|
See also: Derivative from the linked: |
Beta Was this translation helpful? Give feedback.
-
|
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.) |
Beta Was this translation helpful? Give feedback.
-
|
I also updated the linked post of context where the relative hint maybe somehow excessive. My original design (full "CE" style) is inclined toward historical usage: Handling leap seconds whatever wouldn't matter for this context: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
That's exactly the same response you gave on 10/14/2021, 05:13:38. |
Beta Was this translation helpful? Give feedback.
-
|
I have a bookmarklet to make the relative datetime to be absolute when I need javascript: (() => {
document.querySelectorAll("relative-time").forEach(function (element) {
if (!element.shadowRoot) {
return;
}
element.format = "datetime";
element.hour = "numeric";
element.minute = "2-digit";
element.second = "2-digit";
});
})(); |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thank you! What's more: Although my favorite mobile browsers don't seem to support actual bookmarklets (i. e. javascript snippets saved as bookmarks), this one got me really interested ... Today, I've found a viable workaround in Cromite mobile, as it turns out there is one slot for a bookmarklet that works: the Home page address! So, simply tapping If you (like me) can afford the Home page button, that's a surprisingly effective remedy for this issue that, after close to three years, didn't leave much else to hope for. UPDATE 2024-10-03: I've switched to using this improved bookmarklet by @MasterInQuestion instead, which displays UTC in ISO format. |
Beta Was this translation helpful? Give feedback.
-
|
Chromite does support bookmarklets, press CTRL+SHIFT+B to toggle it your bookmarks bar (if it's hidden), add any regular bookmark, edit the bookmark url with the bookmarklet code.
|
Beta Was this translation helpful? Give feedback.
-
|
The difficulties with bookmarklets addressed in my previous comment are entirely referring to mobile browsers. Sorry about the ambiguity, I've edited the comment to clarify. In Cromite for Android, Anyway, having multiple bookmarklets at hand would be nice for sure. For the time being, I'm happy with the single bookmarklet "Home page" workaround. |
Beta Was this translation helpful? Give feedback.
-
|
Outright navigate? Worked for Firefox. Additionally, I have some doubts on the effectiveness of the selected element manipulation: |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Greetings. Shall assist debugging: Thanks for assistance. |
Beta Was this translation helpful? Give feedback.
-
|
Up: https://github.com/orgs/community/discussions/5972#discussioncomment-10834725 Thanks for testing. I'm also testing several possible ways to make uBO auto-inject the JavaScript on relevant pages. |
Beta Was this translation helpful? Give feedback.
-
|
It's been 3 years, still we need to use plugins.... |
Beta Was this translation helpful? Give feedback.
-
|
I really do wish GitHub would address this. It's bad enough on social sites -- I prefer absolute date/timestamps in all cases involving written communication, at least prose other than dates/times in direct quotes -- but this is not a casual social site; the actual date and time really matters for events here. Looking at the history in this discussion, it's interesting that older comments do have absolute dates (e. g. |
Beta Was this translation helpful? Give feedback.
-
|
If you want a quick one-time check for the absolute time, just right-click the date, then inspect. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the suggestion, but unfortunately, that's just another variant of the "hover for a tooltip" non-solution, suffering from the same flaws. See e. g. this subthread. |
Beta Was this translation helpful? Give feedback.
-
|
This is not social media. Most of us work with exact dates. If in doubt, run a poll. |
Beta Was this translation helpful? Give feedback.
-
|
Even social media the time should still help. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the link. I liked you suggestion: upvoted it. I can add Japanese to your examples, who show strange affection towards imperial years - though most people cannot do basic year arithmetic with them. I am writing a project summary using ticket submission dates, and this lack of concern from GitHub just drives nuts. |
Beta Was this translation helpful? Give feedback.
-
|
Somehow similar to "Old-style Chinese date" I mentioned before. |
Beta Was this translation helpful? Give feedback.
and others
Thank you for your suggestion! We will track this issue internally :)