Improvements to updated date

[victorlin]

nextstrain.org preview

Description of proposed changes

Don't render improperly formatted dates and add a relative date in the byline.

Related issue(s)

N/A

Checklist

• Checks pass (ignore failing downstream PR workflow)
• If making user-facing changes, add a message in CHANGELOG.md summarizing the changes in this PR
• (to be done by a Nextstrain team member) Create preview PRs on downstream repositories.
• Post-merge: consider extending the schema to support an exact ISO datetime (ref)

[jameshadfield]

(I haven't run the code, just reading it)

How does this work for very recent dates? In augur export the updated string uses time.strftime('%Y-%m-%d') which'll use the users local time. Our schema says nothing about time zones. I presume (?) moment's also interpreting the date string in the (Auspice) users' local time zone (or is it UTC?).

So what happens if, e.g., I update a dataset right now, thus getting "2023-12-13" and someone in the US views it (the US is currently Dec 12th)... is the dataset updated "tomorrow"? Do we ignore it because it's a bad value? What about the inverse situation, would the dataset appear to me to be updated "yesterday" even if it'd been updated 5 min ago? Time zones make this hard!

[jameshadfield]

It'd be useful to create a table or similar testing different values here. From the datasets on the Auspice review app, long-ago updated datasets do look better than before, e.g. "Data updated 2 years ago" is better than a YYYY-MM-DD string!

[victorlin]

Good point, and very important to consider since we have daily ncov builds.

There's really no good way to handle this with the current schema. The same thing could be said for the current implementation of displaying meta.updated as-is without any time zone info.

I think the difference is that relative dates must assume a time zone whereas displaying as-is leaves it ambiguous (though this could be communicated better), and that its effects are greater for recent dates. Continuing your example, "tomorrow" sounds much worse than "2023-12-13", but "3 years ago" zooms the perspective out to a point where time zone doesn't matter.

How about we only show relative dates if it's at least a week old?

[victorlin]

Going further, we could extend the schema to support an exact ISO datetime (e.g. 2023-12-12T21:47:18Z) which then allows proper conversion to the user's timezone.

[victorlin]

Updated so that the most granular relative date is "in the last week":

auspice/src/components/info/byline.js

Lines 114 to 119 in a89abcf

	const relativeDate = date > DateTime.now().minus({ weeks: 1 }) ? t("in the last week") : date.toRelativeCalendar({ locale: language });
	return (
	<span>
	{`${t("Data updated")} ${relativeDate} (${metadata.updated}). `}
	</span>
	);