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: 28 comments 51 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.
-
|
It looks like more distant dates have been improved somewhat for granularity (e.g., @taki-on's original answer: "Oct 14, 2021" instead of "3 years ago"). However, this does not apply to more recent changes ("2 weeks ago" is still present) and it also does not include times. GitLab supports absolute date-times and has for quite some time (docs). Their implementation is exactly what I would have expected in GitHub, including the localized date-time format ("September 3, 2022, 3:57 PM"). Based on the activity here and in other threads, it seems clear that a large number of developers need this granularity. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
ISO-8601 has poor human-readability and is too drastic of a change. I love the ISO-8601 standard and its principles, but please don't push for that from a UX perspective. Similarly, the vast majority of users do not want to translate from UTC to their local time zone. APIs and data stores use UTC. UIs use localization.
You make a great point here in favor of expressing date-times instead of dates. Dates (when times are not included) are specific to their locale, and it is not possible to apply localization. A commit or post on "Nov 24" is highly ambiguous if we are on opposite sides of the world. It could mean your "Nov 24" or my "Nov 24" -- probably the latter -- which in turn means it could have been Nov 23, Nov 24, or Nov 25 for you. The bigger issue shows up when people start using dates as references. E.g., "invisiblepancake's reply above on Nov 24". The date on invisiblepancake's post will actually show as Nov 25 if you're in any part of eastern Asia. Those of us who work internationally eventually learn to stop assuming dates are global. It would be helpful if GitHub dates reflected that by including times. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
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 |
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.
-
|
Hovering is not even possible with touch input like phones. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Rephrasing, there is no way to view the full date on the major smartphones with the major browsers (99%+ market share). |
Beta Was this translation helpful? Give feedback.
-
|
有在 |
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
@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.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
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.
-
|
Same thing with screenshots. How the hell can I make a point with a screenshot saying "Yesterday"? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
-
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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 arithmetics with them. I am writing a project summary using ticket submission dates, and this lack of concern from GitHub just drives me nuts. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
+1 , I like the exact time |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
+1 from me here. I would love it if this were a personal setting, perhaps under "Settings" => "Appearance", you could add a "Timestamps" setting. Defaulted to the current, relative 'time ago' format, but allowing us to opt-in for an absolute formatting (e.g., YYYY-MM-DD HH:mm:ss). |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
+1
Even when viewed in the morning, it's not intuitively clear what time the post was made. |
Beta Was this translation helpful? Give feedback.
-
|
Much like their surveys, it feels like Microsoft doesn't really care all that much. 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. |
Beta Was this translation helpful? Give feedback.
and others
Thank you for your suggestion! We will track this issue internally :)