Should we remove redundant info in saved date string?

[we-ai]

Some of our saved data need only date (hour, minute and second are not needed), but to make date string fit ISO string "T00:00:00.000Z" is added to end of date. For example we get "2023-12-08T00:00:00.000Z" after concatenating today's date "2023-12-08" and "T00:00:00.000Z" strings. This creates a problem: the above ISO date string translate to 12/7/2023 7:00:00 PM (EST). Parsing such date string is thus error prone and needs special care.
Should we just save the date when we only need date? For example, if we want to save today's date, just save "2023-12-08".

[bransteitterbr]

I can only think of 3 valid ways to store a date the UTC string ("2023-12-08T00:00:00.000Z"), the local time string ("2023-12-08T00:00:00.000"), and just the date string ("2023-12-08"). I think the simple date string is probably the easiest to work with because it will always display the same for all users regardless of their time zone. And if it needs to be compared to a Date Time string it is trivial to append either the UTC or local time midnight string when initializing a date object.

[JoeArmani]

All I have to add is if we go this route, we need to be sure to retain the leading zeros in MM & DD for sorting. My biggest question would be is it worth the added complexity of asking whether a date needs an ISO 8601 string or a simple date string in each case?

Either way, if handling has been error-prone, it probably makes sense to keep a timeHandling.js (or similar) file in each app and perform time validation and time-transforming operations through a pre-set series of functions.

If we're after a reduction in stored data, I think all the extra 'no' values that are stored by default as well as unused tube data in the specimen docs are places to start -- where null values could be handled but 'no' (104430631) values are recorded instead. That's a significant amount of data. This would have to be in coordination with the data team.