Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to updated date #1731

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

victorlin
Copy link
Member

Description of proposed changes

See commit messages.

Related issue(s)

N/A

Checklist

package.json Outdated Show resolved Hide resolved
Comment on lines 116 to 117
{`${t("Data updated")} `}
<Moment locale={language} date={metadata.updated} fromNow />
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 victorlin requested a review from a team December 12, 2023 01:22
@victorlin victorlin temporarily deployed to auspice-victorlin-updat-cl8xfu December 12, 2023 01:23 Inactive
@victorlin victorlin temporarily deployed to auspice-victorlin-updat-cl8xfu December 12, 2023 19:44 Inactive
return (
<span>
{`${t("Data updated")} ${metadata.updated}. `}
{`${t("Data updated")} `}
<Moment locale={language} date={metadata.updated} fromNow />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Member Author

@victorlin victorlin Dec 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines 116 to 117
{`${t("Data updated")} `}
<Moment locale={language} date={metadata.updated} fromNow />
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 victorlin temporarily deployed to auspice-victorlin-updat-cl8xfu December 12, 2023 23:10 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants