Migrate to date and time utils from frontend-shared

[acelaya]

Depends on hypothesis/frontend-shared#1726

Use date utils from frontend-shared instead of local implementations.

Additionally, a remaining standalone function called formatDateTime has been renamed to formatSortableDateTime, to differentiate from the formatDateTime now provided by frontend-shared.

The reason to choose this name is that the format returned by this function is YYYY-MM-DD hh:mm, which produces values that are sorted chronologically when sorted alphabetically.

TODO

• Find a better name for the local formatDateTime function, to avoid confusions with frontend-shared one, which returns a different format.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.42%. Comparing base (a6bc6a9) to head (3f3c9cd).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6587      +/-   ##
==========================================
- Coverage   99.43%   99.42%   -0.01%     
==========================================
  Files         270      270              
  Lines       10240    10169      -71     
  Branches     2425     2417       -8     
==========================================
- Hits        10182    10111      -71     
  Misses         58       58              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[robertknight]

In reviewing this I realized that we've lost the context around why we use this particular date time format for text exports. I think the rationale was to have a human friendly version of the ISO date time format. Can you remember any other reasons? Lexicographic sortability isn't an obviously critical thing in this context.

[robertknight]

Can you remind me why we needed to use a date/time format that has this lexicograph / chronological sorting equivalence?

#6079 was the PR that introduced the change, but the only rationale in that PR was to have a more human-friendly form of the ISO date.

[acelaya]

In reviewing this I realized that we've lost the context around why we use this particular date time format for text exports. I think the rationale was to have a human friendly version of the ISO date time format. Can you remember any other reasons? Lexicographic sortability isn't an obviously critical thing in this context.

Yeah... This is unfortunate, but I also don't fully remember why we choose this particular format.

I can only guess it was so that in the case of, for example, CSV, resulting datasets could be sorted by that column, but I'm only speculating here.

I'll try to dig a bit further into old discussions and PRs.

[acelaya]

I've been digging a bit, and I think we went with this format because it is the format used in the examples originally provided by the product team here https://docs.google.com/document/d/1Xn6AazKkpUy85VUaj9v_utasexk8lIqP_1zveILq1So/edit

The format there includes seconds as well, but I remember discussing we didn't need that much precision and we left it at 2023-08-27 23:12.

[acelaya]

Oh, I found this other PR where this function was implemented #6078

It mentions not only the fact that those dates can be sorted, but also that they are detected as "date" by most common spreadsheet editors.

I'll add that to the function comment as well.

[robertknight]

LGTM with some small requested changes.