Clarification of timezones for time-based data fields

Question

In relation to the time-based data provided through the Get Metrics API for the various fields: currentDay, previousDays, currentMonth, previousMonths. Should these values be based on the time of the call translated to the currentDay/Month as at ‘permanent AEST’ or aligned to the ‘current day’ of the ‘requestTime’?

Guidance from the ACCC for the (six monthly) data in the Reporting forms for Rule 9.4 was that UTC-based aggregation for each period (including number of requests, rejections etc.) was acceptable as long as that basis was noted in the submitted report.

Answer

As it currently stands the Consumer Data Standards (CDS) are silent on what timezone is required for time-based fields. The metrics reporting timezone is at the discretion of the Data Holder. It is not dependent on the timezone in which the Data Holder conducts business.

The Data Standards Body (DSB) recommends a timezone convention where Data Holders are not constrained by other issues. See CDS-DC-006, Timezone of metrics data.

The DSB also recommends a current day convention. See CDS-DC-007, Metrics reporting current day. 

Reference issues and discussions:

On ‘Permanent AEST’ for traffic periods: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/47#issuecomment-560096824

On ‘Offset with reference to UTC’ for date formatted values: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/98#issuecomment-576224178