openstreetmap
Update relative timestamps dynamically
Sometimes I view a recent changeset (say, within the last few minutes), switch to another tab, and come back to it after several hours or even a couple days. The timestamp on the changeset is still relative to when I loaded the page. There’s no indication that the timestamp has gone stale, so sometimes I get confused for a moment before realizing what’s going on. Then I have to either hover over the tooltip and do some math or reload the page. This is more of a problem for recent timestamps than older ones, which are already less precise to begin with.
Many sites, including GitHub and some newer parts of MediaWiki, include some client-side JavaScript that refreshes each timestamp periodically on a backoff timer. These days, we can implement relative date formatting using the Intl.RelativeTimeFormat API, which takes a quantity and a unit. Browser implementations of this API are based on CLDR date formats, which differ from rails-i18n translations in some cases. For consistency, as part of this feature, I suggest changing the served page to use absolute date formats and relying on client-side JavaScript to relativize it in the first place.
CLDR has more comprehensive language coverage than rails-i18n but lacks strings for approximate relative dates: https://github.com/openstreetmap/openstreetmap-website/issues/5769#issuecomment-2723097448. I’d suggest that strings like “about 11 years ago” are counterproductive anyways. Users commonly want to know the year of such an old timestamp, but “about 11 years ago” can only tell them the year, give or take a year. Instead, most sites display an absolute date beyond a certain age. For example, GitHub goes from “just now” to “yesterday” to “2 days ago” to “last week” to “Oct 14”. This could address most of the need for absolute dates in #631. However, moderator-facing pages that require more precision would continue to show absolute dates consistently: #907.
I suggest changing the served page to use absolute date formats and relying on client-side JavaScript to relativize it in the first place.
Can this be done without creating content flicker, where the html version appears first before the JS overwrites it?
If not, or if that's complex to implement, then I'd prefer to continue serving the relative dates in the HTML and the JS can lazily take over updating it a few seconds after page load. The timestamp is already in the "datetime" attribute of the surrounding <time> tag so the JS can use that as the base.
Yes, we can avoid a user-perceptible relayout by hooking into the DOMContentLoaded event. If we were to do a lot of work in the event handler, the user would notice a delayed relayout, but we hardly use this hook for anything yet, and replacing the contents of a few <time> tags with formatted dates would be very efficient.
I think this would be easier than ensuring consistency between server- and client-formatted timestamps. As far as I can tell, these days, rails-i18n is unusual among standard library environments for not directly using CLDR for date formats or their translations.