4 ms·

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 w

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.

pavel_lishin 3y ago
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.
- crtasm 3y ago
  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 https://greasyfork.org/en/scripts?q=jira
  - pavel_lishin 3y ago
    Ooh, I'll see if I can do that this week.
- jbaber 3y ago
  I think I'm at 8 different greasemonkey scripts to manhandle Jira.
john_cogs 3y ago
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#show-exact-times-instead-of-relative-times https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
- simon04 3y ago
  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.
  - finite_depth 3y ago
    [dead]
  - Am4TIfIsER0ppos 3y ago
    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.
  - gsich 3y ago
    >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.
    - IIsi50MHz 3y 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.
      - gsich 3y ago
        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...".
zoky 3y ago
> 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.
- djha-skin 3y ago
  Date calculations are really easy for most people. Even in this case I just think I would be annoyed.
Izkata 3y ago
> 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
- makeitdouble 3y ago
  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.

pavel_lishin 3y ago

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.

crtasm 3y ago
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 https://greasyfork.org/en/scripts?q=jira
- pavel_lishin 3y ago
  Ooh, I'll see if I can do that this week.
jbaber 3y ago
I think I'm at 8 different greasemonkey scripts to manhandle Jira.

john_cogs 3y ago

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#show-exact-times-instead-of-relative-times https://docs.gitlab.com/ee/user/profile/preferences.html#sho...

simon04 3y ago
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.
- finite_depth 3y ago
  [dead]
- Am4TIfIsER0ppos 3y ago
  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.
- gsich 3y ago
  >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.
  - IIsi50MHz 3y 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.
    - gsich 3y ago
      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...".

zoky 3y ago

> 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.

djha-skin 3y ago
Date calculations are really easy for most people. Even in this case I just think I would be annoyed.

Izkata 3y ago

> 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

makeitdouble 3y ago
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.