Hacker News Reader

Comment by makeitdouble | Hacker News Reader

One aspect that is so disturbing with the fuzzy display is when the day of the week is the most relevant info.

Looking at gitlab's history for instance, it's way more helpful to know if it was merged on friday than "last week" or "2 days ago".

Same for chat history etc. happening at the limit of a month, knowing exactly if the discussion happened before or after the beginning of the month can matter a lot.

For everything else I personally could care less if it was 4 weeks ago or 2 months ago, so getting the exact date also doesn't deprive me of info.

I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.

View on HN

GitLab team member here.

You can use absolute times (ex: October 14, 2023 11:51AM) instead of relative times in GitLab by changing your preferences: https://docs.gitlab.com/ee/user/profile/preferences.html#sho...

I'm waiting for the day when I can additionally configure "use ISO8601/RfC3339 timestamps"

Not only on GitLab, but everywhere. In any application. On any website. It's a pain in the ass on Linux.

God yes. That should be just the locale. I have it set up right because `date` shows it correctly but nothing else respects it. Not Dolphin, not Thunderbird, not git.

>Not only on GitLab, but everywhere. In any application. On any website. It's a pain in the ass on Linux.

C.UTF-8, but you are correct. Windows solved this years ago.

…?

I must be misunderstanding you.

I can't get ISO-8601 dates to work properly in Excel unless I set my Windows to Australia locale, or make my own parser or use a third-party library.

Sure, I can format a field^Wcell with a custom format string, but Excel still won't believe me when I type/paste/import ISO-8601 dates. Unless I set 'Australia' systemwide.

And no, simply adding English (Australia) as one of the additional system languages, or keyboard layouts (and switching to that layout), or number+date+currency formats doesn't work.

Oh, works here. I set locale format to German (Germany) or (Austria) while using Windows with English language. All date/time/currency formats are sane.

But you could also customize the region settings in "Additional settings...".

Good to know there are other countries with sane defaults. (-:

For some insane (=AM/PM) reason the language is tied to time preference.

Worse, there are clearly conflicting sources of truth involved.

Setting locale to `en_SOMEEUROPEANCOUNTRY` will make some programs use ISO 8601 dates everywhere, but other programs use all sorts of random formats. Switching between countries changes what different subsets of programs do.

Throwback to when Google maps randomly chose to use km/h configured in android settings and "mph (auto)" from google account setting at once on the same screen in the app.

I found that setting language to UK instead of US avoids a lot of the goofiness like YY/DD/MM and 12h time. Setting the language to my native tongue instead of English just doesn’t work for all the industrial terms.

Yes, but Gitlab doesn't have that.

Thank you for supporting this. Anyone know if GitHub has a similar option?

Why isn't this the default?

Instead of providing a useful meaningful date, you:

- obscure information

- spent additional devtime creating a time conversion

- spent additional time implementing an otherwise useless setting for this

Why?!

I wrote a Greasemonkey script to replace Jira's useless time labels with the full date, including the day of the week. Highly recommend doing this for any browser-based software you use regularly.

I don't use Jira but suggest sharing it on GreasyFork for those that do.

There's loads of scripts on there for Jira but I didn't see any for the dates: https://greasyfork.org/en/scripts?q=jira

Ooh, I'll see if I can do that this week.

I think I'm at 8 different greasemonkey scripts to manhandle Jira.

> I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.

It can be, in niche scenarios. I have an application that pulls information in from another database, reformats it, and displays it for the user. The update is expensive and time-consuming, so it has to be triggered manually by the user when it is needed. In this case, the exact time of the last update isn’t particularly useful; the only thing that matters is how old the data is, which is to say how likely it is to be out of sync with the source of truth. In some cases, information needs to be as up-to-the-minute as possible, so if the info is just a few hours old it needs to be refreshed. Other times, information that is 4 or 5 days out of date or longer is totally fine, so there is no need to trigger an update that could take as long as 10 minutes.

For this particular purpose, fuzzing the date is actually more useful that providing the time of the last update, since order-of-magnitude precision is good enough, and it saves the user from having to compare the update time to the current time and do a calculation. Admittedly though, this is a rare case, and the vast majority of the time a relative fuzzy date is less helpful.

Date calculations are really easy for most people. Even in this case I just think I would be annoyed.

> I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.

I use it for communicating short-term times in the future when the recipients are across multiple time zones: "___ will finish running around 4-5 hours after this comment", "___ is fixed and will start its next run about 15 hours after this comment", etc

Thanks, this is one I am 200% behind. Youtube does this well too, knowing that a feed will start in 5h or 2 days is more helpful than the exact date I'd have to calculate from today.

I think that's the proximity and actionability that makes the difference.

Reply on news.ycombinator.com