Consider using duration strings for attribution expiry

[jyasskin]

The <time> element accepts a duration format parsed by https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#parse-a-duration-string. It might be more ergonomic to accept the same format in the new <a attributionexpiry> attribute in this spec, rather than the Javascript-centric number of milliseconds.

[apasel422]

@johnivdel This does seem more ergonomic, especially since I can't see the value in millisecond precision for this field.

[johnivdel]

Agreed on the points above.

To go a step further, I wonder if we could just accept expiry as an integer number of days.

The View explainer requires expiries to be rounded to the nearest whole day. While clicks do not have quite the same privacy properties, it's hard to judge if the additional granularity gives sufficient utility to justify both the input format complexity and the complexity when handling "bad" inputs.

cc @csharrison @maudnals

[csharrison]

We chose this by following the advice in https://w3ctag.github.io/design-principles/#milliseconds. I'm OK with something more ergonomic but I think we should consider filing a bug on TAG if the advice is generally applicable.

[apasel422]

Re https://github.com/WICG/conversion-measurement-api/issues/132#issuecomment-885725383, that guidance is under the header "Web IDL, Types, and Units", so does it actually apply to this issue, which is suggesting a format for the attributionexpiry <a> attribute?

[csharrison]

@apasel422 good point. I don't know if it strictly applies, but it felt like the logic generally applies across all web platform APIs:

Even if seconds (or some other time unit) are more natural in the domain of an API, sticking with milliseconds ensures that APIs are interoperable with one another. This means that authors don’t need to convert values used in one API to be used in another API, or keep track of which time unit is needed where.

That being said I don't think this is a hard blocker to make the API more ergonomic.

[jyasskin]

+1 for filing an issue against the design principles to see if the TAG wants to take a stance one way or the other.

[csharrison]

It looks like milliseconds might not have been the right choice. Especially now that we may be moving to response-based registration we should try to match other header-based APIs for time format. I see two alternatives:

1. Delta seconds (caching, Age, Retry-After)
2. HTTP-Date (Retry-After)

It seems like Retry-After uses both delta-seconds and http-dates. I am not sure which is more standard for new HTTP-based APIs but given that these will likely be embedded in JSON or similar structure, I am inclined to use the simpler format and go with seconds.