When rounding source_registration_time, would adtech want to specify the timezone

[palenica]

The aggregate API explainer says that source_registration_time will be rounded to the nearest day boundary. The explainer does not explicitly specify a time zone, but the assumption is we'll round to day boundary in UTC timezone.

Question: Is there appetite for the adtech to be able to specify which timezone to use to define day boundaries?

[RussStringham]

I cannot speak for ad tech, but Adobe's web analytics customers definitely would want this rounded to the day boundary in their preferred time zone.

[appascoe]

As far as NextRoll is concerned, we greatly prefer UTC in all of our logs, with any translations (say for a customer) happening downstream.

[RussStringham]

If they round to the nearest day, you cannot translate downstream.

[appascoe]

I know what you mean, but that's not what I meant. We would just take the UTC timestamp of the bucketed day and translate that for the customer so they understand how the bucket aligns with their own timezone. As for rounding down to some date based on the user and then bucketing that? That's not something we would want. For example, if we rolled out some change (tracked in UTC), we would want to clearly see what its effects are within a single UTC bucket, and it's more desirable and valuable for us to have that be consistent across users.

[palenica]

Just to be clear: the reason we're porposing to round the timestamp to a day boundary is to limit the amount of entropy revealed. If you accept the premise that "rounding to a day on the client" is a requirement for privacy reasons, it makes sense to discuss whether it's worth allowing the API user to define day boundaries, and how to do that in a practical and privacy-friendly way.