Require all timestamps to align with time_precision (*)

[cjpatton]

Prescribe that all timestamps and time intervals are a multiple of
time_precision.

This is already required in most situations, but we are currently
missing at least one edge case: Aggregators are meant to reject reports
with timestamps that precede the task start time, but the Client is also
supposed to round down its timestamp, meaning it may get rejected even
if upload time is valid. This case is solved by the new requirement.

This also means that we must lift "Clients SHOULD truncate report
timestamps" to "MUST". Following the principle that "MUST must be
enforced", require rejection of reports with malformed timestamps during
aggregation.

Note: this is a breaking change since we're being stricter about
contents on the wire.

[branlwyd]

Eh, I think this is optional: an implementation/deployment could allow the task_start time to only be a multiple of the time precision, for example -- which is a good idea since, due to client timestamp rounding, time_precision is effectively the smallest meaningful unit of time. Or the deployment could pre-date the task_start time with enough of a "margin" that rounding the client timestamp doesn't break things.

If we do want to keep this, I suggest we drop the task_start - (task_start % time_precision) notation and instead simply suggest rounding down to the nearest multiple of the task's time_precision. I think this would be easier to follow, and would match how we describe the client's behavior: "The Client SHOULD round this value down to the nearest multiple of the task's time_precision in order to ensure that that the timestamp cannot be used to link a report back to the Client that generated it."

[tgeoghegan]

The proposed change fixes this specific issue, but it's possible there are other places in DAP where we handle time and might make a similar mistake. Rather than fixing these one by one, we could instead assert that all times in DAP (including task_start and expiry) must be rounded to the task's time_precision, which would fix everything at once.

[cjpatton]

@branlwyd the reason I don't think this should be optional is that it's a case where rejection is systemic to the protocol. Clients are encouraged to truncate times tamps, but if they do, then their report might get rejected depending on the value of task_start.

I took your editorial suggestion.

@tgeoghegan nice observation. Let's discuss potential solutions in the DAP sync today.

[cjpatton]

2025/1/15 call: wherever we have a timestamp, round it down to the nearest multiple of time_precission.

[cjpatton]

Alright, ready for another round here. Note that this is not quite a minimal change.

[cjpatton]

Do we want a new report error variant here?

[tgeoghegan]

I don't think so. It's hard to imagine any client out there that would first try an unrounded timestamp, then gets error your_timestamp_sucks and then goes "OK, FINE, I'll round it down!" Transmitting an unrounded timestamp in a report just suggests a defective client that isn't ever going to succeed.