Currently the main release of relative time uses a 90% rounding rule for dates.
Relative times are colloquial and so every user interprets them in subtly different ways. There are a few techniques we have used in the past:
We go on the literal date unit. So at 12:01AM a post from 2 minutes prior would say "a day ago". A post on the 31st December, when read on 1st Jan, would say "last year", which feels inaccurate.
We round units to some amount, so if the delta is 2 minutes we say "2 minutes ago" until minutes can be rounded up to hours at which point we can say "1 hour ago". We can pick the threshold for this...
A threshold of 50% would mean something 30 minutes ago would be "1 hour ago", and something 6 months ago would say "last year". Having a low threshold for larger durations seems inaccurate.
A threshold of 90% would mean something 54 minutes ago would be "1 hour ago", something 11 months ago would be "last year". The downside to this is that occasionally you'll get rounding such as something being 20 months old saying "last year". Having a high threshold seems inaccurate.
Right now the 90% threshold is our latest iteration but it has problems with large units of time, chiefly months and years. At the time of writing, for example, dates from April 2021 will be marked as "last year" despite being much closer to "2 years ago".
This PR changes the logic just for months and years to use a similar mechanism to that described in Temporal.Duration.round. We take the relativeTo which is a date, and we execute calendar math on the date object - working out the delta of the current month and rounding based on calendar year instead of a rounding of months.
This means for dates that have a delta of months or years, they will perform calendar operations, and those dates will be relative to the calendar year. In other words a date from 2022 read in 2023 will only ever read as "last year" and not "2 years ago", meanwhile a date from 2021 read in 2023 will never say "last year" and will always say "2 years ago".
:wave: Hello and thanks for pinging us! This issue or PR has been added to our inbox and a Design Infrastructure first responder will review it soon.
:art: If this is a PR that includes a visual change, please make sure to add screenshots in the description or deploy this code to a lab machine with instructions for how to test.
:fast_forward: If this is a PR that includes changes to an interaction, please include a video recording in the description.
:warning: If this is urgent, please visit us in #primer on Slack and tag the first responders listed in the channel topic.
Currently the main release of relative time uses a 90% rounding rule for dates.
Relative times are colloquial and so every user interprets them in subtly different ways. There are a few techniques we have used in the past:
Right now the 90% threshold is our latest iteration but it has problems with large units of time, chiefly months and years. At the time of writing, for example, dates from April 2021 will be marked as "last year" despite being much closer to "2 years ago".
This PR changes the logic just for months and years to use a similar mechanism to that described in
Temporal.Duration.round
. We take therelativeTo
which is a date, and we execute calendar math on the date object - working out the delta of the current month and rounding based on calendar year instead of a rounding of months.This means for dates that have a delta of months or years, they will perform calendar operations, and those dates will be relative to the calendar year. In other words a date from 2022 read in 2023 will only ever read as "last year" and not "2 years ago", meanwhile a date from 2021 read in 2023 will never say "last year" and will always say "2 years ago".