feat: display human-friendly timestamps in locks and jobs tables #5542
+45
−5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
what
It is often times easier on the brain for human-facing parts of tooling to have relative timestamps such as "just now", or "4 days, 9 hours ago" rather than a YYYY-MM-DD HH:MM:SS timestamp. It allows for a more intuitive understanding of when something happened. This PR replaces 'Date/Time' columns in the Locks and Jobs tables with 'Lock Age' and 'Job Age' columns, which display relative times but still can show the precise timestamp in a tooltip when the mouse pointer is hovered.
why
I was tired of doing math to calculate how long a lock has been held in a workspace or project, or how long ago a certain action such as a plan or apply happened. Then factor local/UTC conversions into it, and I asked myself "why can't it tell me like a person would?".
tests
I added a fake value in JobIDInfo to account for JobAge, just following the pattern I see, but I'm open to suggestions. I'm not a software engineer and I don't pretend to be one. I just scratch itches.
references
None
Other
I'm not sure what the implications are when changing text like this. The first thing that comes to mind is that it would break someone's screen scraping or automated parsing? Would this pass a sniff test if it was enabled/disabled via server-side config?