Representation of time within EnergyPlanDetail Schema

[CDR-API-Stream]

Description

As part of feedback on issue #472, request was made to align how time is represented within EnergyPlanDetail Schema.

This issue has been raised to consult on the request.

Area Affected

EnergyPlanDetail Schema

Change Proposed

This decision proposal is currently a placeholder. The DSB will publish recommended changes to be consulted on within the Maintenance Iteration it gets prioritised for.

[CDR-API-Stream]

This CR is now included in MI11. This is a result of re-prioritisation work the DSB carried out as per action raised in MI11 session on 25th May.

Background

The following fields describing time within EnergyPlanTariffPeriod are currently defined as type “string”, the description stating that time would be in HHMM format using 24 hour clock format:

• timeOfUseRates.timeOfUse.startTime
• timeOfUseRates.timeOfUse.endTime
• demandCharges.startTime
• demandCharges.endTime

This was done in collaboration with the EME/AER team followed by several energy sector consultations conducted last year.

During consultation of issue #472 in MI11, participants indicated the desire to have all time attributes type defined as TimeString to ensure consistent representation of time within EnergyPlan schema.

Proposed change

The DSB has discussed this with EME/AER and proposes to make the above change. The change would also be applied to time fields in the proposed controlledLoad changes being discussed in #472.

[biza-io]

We support the change of these fields to TimeString.

[DannyDuong]

Problem description
The change from representing time values in HHMM in local time, to representing time values offset to UTC makes it impossible to accurately represent time values for tariff periods covering dates with and without Daylight Saving Time (DST) applied. The values represented as TimeString will either be offset relative to UTC by 10 or 11 hours in Victoria, depending on DST being applied or not, meaning tariff periods covering both dates with and without DST can only be correct for one group of these dates, not both. The time values impacted may exist in various components of the energy plan, including Time Of Use periods, demand periods, and controlled load periods.

Currently there are no plans in Victoria with tariff periods matching DST and non-DST dates, making virtually every plan susceptible to the issue. Furthermore, DST dates may start and end on different dates on different years, meaning the offset may be different when looking at tariff period dates on different calendar years.

Example
Plan with Time Of Use tariffs with standard peak period from 3pm to 9pm.
• Previously represented as HHMM:

• Now represented as TimeString offset relative to UTC:

The above timestamps, while correctly offset for the start and end dates of the tariff period (1st January, 31st December), would be incorrect for the non-DST period within the tariff period. For example, in Victoria in 2022, DST was not applied from 3rd April 2022 to 2nd October 2022.

For the non-DST period, the below offset would be accurate instead:

Suggestion
We suggest continuing representing time values as HHMM in local time so they can be accurately applied to tariff periods. Times offset to UTC are also more difficult to read, especially in the context of covering 24 hours per day.

[perlboy]

The proposal doesn't seek to specify a time offset to UTC but rather an RFC3339 formatted time in alignment with the rest of the Standard which includes the ability to specify any offset an implementer likes (allowing the receiver to do any time math they like to suit their use case).

I believe the suggestion above is based on a desire to specify no timezone, there's actually an allowance for this in RFC3339:

Unknown Local Offset Convention
If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00". This differs
semantically from an offset of "Z" or "+00:00", which imply that UTC
is the preferred reference point for the specified time. RFC2822
[IMAIL-UPDATE] describes a similar convention for email.

Further the issues with HHMM were highlighted in my reply:

5. Timezones appear to be getting defined in descriptions but AER data has something too. RED66349SBE2 for example is defined as AEST in the description but provided as LOCAL in the timeDefinition. This is relevant because it goes to the use of HHMM rather than a timezone qualified CDR TimeString and the fact that, at a minimum, there isn't any time definition field. LOCAL is a commonly used timeDefinition which I guess means "Local Time" but there seems to be situations where this conflicts non-AE[D]ST locations.

The schema for EnergyPlanDetail is embedded in Account Detail responses as well as Generic Tariff Plans. This is relevant because the current format of HHMM leaves it up to Data Recipients to, some how, discover what timezone something is in when it is clear that nationally it isn't consistently "local time". On this basis the adoption of TimeString offers an opportunity to increase such precision while providing a signalling mechanism for when such precision is unavailable or not preferred:

1. Present the start/end time relative to when the call was made (ie. alter the response during DST periods). This is highly useful for Account Detail calls and live "how much is this costing me right now" type use cases that aren't assumed to be in a specific state (ie. QLD never has DST) or;
2. Present a signal of -00:00 indicating "local" time so a Data Recipient can make a decision how to handle it. This could be easily provided for in the description of these fields.

Put another way leaving it as HHMM has the effect of making it impossible to ever have any precision despite the possibility it may be available.

[perlboy]

Just a footnote here, the driver for the request here is less about RFC3339 time (although that's what is available in TimeString) and more about the use of an international Standard time that off the shelf time parsers can handle. I note a pure ISO-8601 time would allow the optional addition of a timezone removing the "unknownness ambiguity" of sticking with RFC3339 so the introduction of an ISOTimeString is a possibility.

[CDR-API-Stream]

This change request was incorporated thorough ConsumerDataStandardsAustralia/standards#249 (comment). A new CR can be raised if the issue needs to be re-assessed