Replace "Friendly Date" format in favor of Date/TimeStamp

[kahopkin]

I love the History, but what is very useless in the gui is how the History of anything is presented. Currently they are using the "Friendly" date format, which is vague and ambiguous, ie: "yesterday, few minutes ago, 2hours ago".

On any page, the date is always in this useless friendly format and it is simply frustrating and makes working more cumbersome.

In order to see the time I made the commit/change, I have to try to find the "sweet spot" for where to hover over (the whole list item is not triggering the hover...)
Date/Time should be in Standard format and not this unfriendly "Friendly" format.

Developers like to be concise, and being able to see actual time stamps next to commits can be extremely helpful when debugging or need to go back in history.
Please either let us choose date format in a settings under our profiles or replace this "friendly" date format with Standard Date/TimeStamp!
We don't want to have to do date arithmetics when trying to match our repos/work with our files on our computers.
If we have multiple of copies of the work on our computers, matching with dates only possible with literally doing date arithmetic.
If we could just see a TimeStamp: 05/10/2022 22:44:17, all guess work would be eliminated.

Also: The user should be able to decide on what date formatting works for them. For example, the 24-hour (as above) format might not work for some people, and they might prefer to see AM/PM style format, other cultures might have different format that they are used to, and we all should be able to choose a formatting style for the date and time stamps. These are very important pieces of data and not seeing exact values is frustrating and cumbersome.

Instead of forcing us to hover over the exact right area to see the timestamp: why not make that default??? Please consider this change!

[ExcuseLme]

can't agree anymore, I just want to see a timestamp, but not an abbreviated month names

[RasmusBruun]

I'd love it if this suggestion was implemented! 🔥

[ghost]

Hi all!

I created an interesting concept based on your idea! What if there was a calendar in the sidebar where the user could, like a time machine, go back and forth with each modification of his repository?

concept/idea

[RobertKrawitz]

Calendars, hovering, and so forth are not useful if I want to cut and paste text or take a screenshot.

[GfEW]

I actually do like the calender / time machine idea, but it's entirely different from (and would likely take much more effort than) possible solutions to the simple datetime display format issue raised here.

[Calinou]

I don't think timestamps are an upgrade in most situations, unless you're taking a screenshot for posterity. As for hovering, I suppose a dummy element could be added around the date to make the hover area larger (and therefore easier to trigger).

What I'd like to see the most is some highlighting for recently changed files (e.g. by displaying the date in progressive shades of orange as the commit date approaches now). This could also apply to issues and comments – I find this beneficial in almost any situation where a relative date is displayed.

[lsehoon]

please please remove friendly dates please 🙏

[chaojian-zhang]

"Friendly dates" are such a hassle. BuildBot has it and it's equally annoying. Microsoft OneDrive also has it.

[lukas-wg2]

I have the same issue with the timestamp, but I don't necessarily think it should be removed. It should just be an option in your GitHub profile that you set like Show relative time and Show absolute time. For me, the biggest headache is the AM/PM as I'm used to 24-hour time format.

[timfrith]

I agree - I would prefer to have the choice in my settings of how to show dates.

[Mariella-Pasamonte]

Where can I find that option?

[diligent176]

Absolute date is what I want to know, 99% of the time.
Could we please have a checkbox for this in Profile / Appearance (near "default emoji skin tone")?
Date formats are far more important than emoji colors. ;-p

@gabor-akeero

[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 so they can work without hassle.
Using UTC as default timezone would be fine for coders/admins, and newbies can easily learn what's the delta to UTC 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.

[RasmusBruun]

I've been working on a Chrome extension for this.

In the current version you can toggle betweeen showing precise, "friendly" or both date formats. You can toggle between Am/Pm, and can show the precise time as either Short, Medium, Long format.

If there is interest in this, I'll go through the hassle of publising it :) (Apparently you have to pay a fee to make a Google Web Store Dev account 🙄)
In the meantime you can find the repo and install it locally here: https://github.com/RasmusBruun/unfriendly-dates

[maddes-b]

@RasmusBruun Please read my comment above yours.

[mzso]

Date should be ISO time though. not that dumb (and ambiguous) format shown in the OP.

[aswen]

Date should be ISO time though. not that dumb (and ambiguous) format shown in the OP.

I would prefer that too, but it's a matter of taste. It's not very friendly to the OP to describe your preference this way.

Wouldn't it be the best if it were a configurable option? One should be able to define it to their own liking. For example using the syntax that the date command supports.

So, @mzso and I would choose %F %T, @kahopkin would probably set it to either %c or %B %d, %Y, %I:%M %p %Z or so.
And if you don't set it: default to relative date/time.

[maddes-b]

That this should be options was mentioned several times in the previous comments: a) date format (ISO, etc.) and b) time zone (UTC)

[GfEW]

On absolute times, and ISO format specifically, there's also plenty discussion and workarounds in #5972.

[YCJDWCJI]

[mstockley-bladebridge]

This is pretty good, but 'az' doesn't seem to provide ISO format. Also, it barely helps on Blame of large files that lazy-load lines as you scroll.

[thomas-maeder]

@MiaoMiao-Xie : thanks a lot!
Unfortunately, I see the "unfriendly" time format only for a fraction of a second, I think (it's hard to tell). After that, the (not so) "friendly" time format appears again.

[thomas-maeder]

Something along the lines of the following works well for me:

function formatDate(dateTime) {
	var date = new Date(dateTime);
    return new Intl.DateTimeFormat(navigator.languages,{
        year: "numeric",
        month: "numeric",
        day: "numeric",
        hour: "numeric",
        minute: "numeric",
        second: "numeric",
    }).format(date);
}

[mstockley-bladebridge]

If only the parts were ordered sanely in my locale! The only way I could find to specify the date order I want (year, month, day) is to format each piece separately and join them after (credit: https://stackoverflow.com/questions/3552461/how-do-i-format-a-date-in-javascript/3552493#3552493). Once that gave me the array-map-join idea, I realized I could adapt it to inject any separator(s) anywhere I wanted; and so was born my overly-complex pair of format_parts array and formatDate function. :) Originally I had all the date pieces on one line and the time pieces on the next so I could easily toggle between date-time and just date while testing, but now I have moved each piece to its own line for the sake of readability.

@thomas-maeder Please do let me know what Tampermonkey disliked about my original set of meta-data. I'd like to make sure the whole script is drop-in ready, but the documentation was not forthcoming about the requirements and restrictions!

[maddes-b]

Try the Tampermonkey solution mentioned in https://github.com/orgs/community/discussions/16550#discussioncomment-4160737

[thomas-maeder]

I have tried reproducing Tampermonkey's problem with the meta-data, but I haven't succeeded.
I must have messed up with the difficult task of copy&paste to cause it...

[mstockley-bladebridge]

@maddes-b I did, and it did not work on Blame pages because they lazy-load after an initial set of lines. Believe me, I don't resort to building my own until I have to! 😆

@thomas-maeder No worries, I think it may have been something I messed up when I originally posted without syntax highlighting. If copy/paste works now, that's all that matters. 😃

[BrendanPC]

I want to add that not only would an absolute timestamp be preferable to a "friendly" date, currently the friendly date is a liar!

This commit was made less than one year ago, but the friendly date claims it is two years old (i.e. it is off by over a year).

[aiqc]

it would be nice if you could control the date format using controls located near the column header. also sort by recent/old.

I'm sick of seeing "last month." that's not helpful

[radekroster]

"Friendly dates" makes me to search for the real date each time something happened more than 10 minutes ago. Nonsense.

[annbelievable]

Gitlab have a setting which lets user switches between a friendly date and actual date, the same could be achieved for github too.

[pkvdesigns]

Came here hoping for a solution, but instead made an Arc Boost to show the actual time below the Friendlytime:
https://arc.net/boost/604D04AC-915C-4C83-BEC8-023466BD96EC

Hope this helps some of you ;)

[GustavTaxen]

I cannot believe that it isn't possible to configure whether you want to see timestamps in UTC, local timezone, or "friendly" format in a service where dates/times are absolutely crucial for reporting and problem solving.

[anhofmann]

Today, I had to explain to the management the “friendly date” thing and that they need to hover with the mouse to see the real date. I can't describe the bewilderment in their faces, because to them, not seeing the exact dates reduces GitHub to an unorganized mess.