List Resources: re-evaluate date parsing calculation

[victorlin]

nextstrain.org/static-site/src/components/ListResources/Modal.tsx

Lines 134 to 146 in aae874c

	function _snapshotSummary(dates: string[]) {
	const d = [...dates].sort()
	if (d.length < 1) throw new Error("Missing dates.")
	const d1 = new Date(d.at( 0)!).getTime();
	const d2 = new Date(d.at(-1)!).getTime();
	const days = (d2 - d1)/1000/60/60/24;
	let duration = '';
	if (days < 100) duration=`${days} days`;
	else if (days < 365*2) duration=`${Math.round(days/(365/12))} months`;
	else duration=`${Math.round(days/365)} years`;
	return {duration, first: d[0], last:d.at(-1)};
	}

from @ivan-aksamentov in #874 (comment):

Another thing is that this entire calculation is wrong. For example, not all years have 365 days. Date-time calculations is a very hard topic, and it is somewhat unreasonable to try and do on the spot. There are specialized high-quality libraries exist to do this correctly, e.g. luxon (continuation of moment.js). And then for human durations there are also small libs (e.g. this). Not even talking about that calendars and durations are different in different cultures.

[tsibley]

+1 for using fully-fledged datetime libraries. For JS/TS, that typically means Luxon. (Having some déjà vu here.)

[ivan-aksamentov]

In this particular case, James convinced me in the linked thread that because the output is for human consumption and vague/approximate by design, then it does not necessarily make sense to spend energy on being pedantic here.

There are many examples of reinventing the wheel in the org's code. And it kinda works. So the team probably has better things to do.

(As of my general preferences, I believe if a precise, typed one-liner requiring no maintenance is available on npm, then it should be prioritized, at least when writing new code)