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: 12 comments 19 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. [ [ |
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.
-
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; )
github.com##span[datetime]:upward(1):style( width: auto !important; )
! Somewhat quirky (to dynamic page loading):
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... |
Beta Was this translation helpful? Give feedback.
Thank you for your suggestion! We will track this issue internally :)