Improvements to updated date #1731
Conversation
nextstrain-bot
temporarily deployed
to
auspice-victorlin-updat-cl8xfu
src/components/info/byline.js
Outdated
| {`${t("Data updated")} `} | ||
| <Moment locale={language} date={metadata.updated} fromNow /> |
There was a problem hiding this comment.
This is splitting translation on a English boundary, so it might not be proper grammar for all languages. Hopefully it still gets point across.
victorlin
force-pushed
the
victorlin/updated-date
branch
from
492ea99 to
68c9bb2
Compare
victorlin
force-pushed
the
victorlin/updated-date
branch
from
68c9bb2 to
f48f071
Compare
src/components/info/byline.js
Outdated
| return ( | ||
| <span> | ||
| {`${t("Data updated")} ${metadata.updated}. `} | ||
| {`${t("Data updated")} `} | ||
| <Moment locale={language} date={metadata.updated} fromNow /> |
There was a problem hiding this comment.
(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!
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
src/components/info/byline.js
Outdated
| {`${t("Data updated")} `} | ||
| <Moment locale={language} date={metadata.updated} fromNow /> |
There was a problem hiding this comment.
One scenario where this change would be unfavorable is in screenshots, where relative dates don't age well. (I just noticed this while watching someone present their Nextstrain build).
There was a problem hiding this comment.
Displaying both would make things more interpretable without compromising screenshots, but maybe that's getting too wordy?
Data updated 3 years ago (2020-12-11)
There was a problem hiding this comment.
Personally, I get irked by relative dates without the ability to see the exact date. I think displaying both would be better.
A bad value could show as an inaccuracy such as "Data updated today", which shouldn't be allowed. I discovered this upon looking at the mers example dataset provided by get-data.sh.
To us humans, "Data updated 3 years ago" is more interpretable than "Data updated 2020-12-11". Time flies!
victorlin
force-pushed
the
victorlin/updated-date
branch
from
f48f071 to
c826b5a
Compare
Description of proposed changes
See commit messages.
Related issue(s)
N/A
Checklist