Download modal should display human formatted date not UNIX timestamp

[corneliusroemer]

Just noticed that we display UNIX timestamp here which is obviously not what we should do here:

[theosanderson]

Probably nice to do this with a generic formatting function that is reused wherever fields are displayed (I can't remember how this works atm)

[fhennig]

The filters that we display in there are taken from the lapisSearchParameters which is just a Record<string, any>. This any is either a list of values, or a string, in the case of releasedAtTimestamp it is a UNIX timestamp string.

This means, at the time of rendering, we don't know the type of the value anymore, so it isn't trivial to render the timestamp (Happy to be corrected of course).

IMO the way to address this would be to improve the code around lapisSearchParameters. getLapisSearchParameters should use the type information from the schema to parse the strings from the URL directly into proper types, and instead of any we should have a union of known types. Then it would be easy to render the Date downstream.

However, the lapisSearchParameters are used in a lot of places in the SearchUI and such a refactoring would definitely take more time than just formatting a timestamp. It would of course make the code more robust, and easier to reason about - in my opinion the use of any here is a code smell and we should fix it - but difficult to say whether now is the right time to do so.

Other options I could think of:

• Devise some sort of heuristic to detect a timestamp and distinguish it from an integer field, and render that. This is however inherently error-prone
• Change the releasedAt type from timestamp to date - the date is serialized as YYYY-MM-DD. (Example for collection date in screenshot below). This isn't great though and we still have the problem if we at some point actually want to use a timestamp.
• We could also try and make LAPIS accept YYYY-MM-DD formatted dates as valid for timestamp filters.

---