date_time issue: timestamps won't match and YSI time as the "representative" time

[akshoelace]

No description provided.

[atn38]

Hey Sasha @akshoelace, allow me to hijack your issue and make it about the larger problem of times not matching up:

In 2022 hopefully we will start collecting not just dates but also times at stations. When we go to collate, these times may not match up, and may not match the YSI timestamps. It's not possible to include all the timestamps, so we decided to just merge based on the dates, and @alinaCO2spera proposed we should still include the YSI time in a column that "represents" the overall time.

[atn38]

Another issue: sometimes there are two or more YSI measurements made in a day. I think we're just gonna have multiple rows for that same day, and all other measurements will be duplicated.

[twhiteaker]

Duplicating other measurements might be confusing to the end user? How would they know what is a replicate sample and what has been programmatically duplicated?

I suggest including the timestamp when assembling data. If samples on the same day have different times, this will result in a lot of null values in the table. Yes it's ugly, but, if the user wants to aggregate, then can do so however they want, such as by day, hour, week, month. Perhaps for convenience, the collation function could have a Boolean option to group by day, with replicates averaged.