Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review ENUM values for representation of days in Energy Standards #502

Closed
CDR-API-Stream opened this issue Apr 12, 2022 · 6 comments
Closed
Labels

Comments

@CDR-API-Stream
Copy link
Collaborator

Description

As part of feedback on issue #472, request was made to align the ENUM values for representing 'days' within the energy technical standards.

This issue has been raised to consult on the request.

Area Affected

Energy APIs

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
Copy link
Collaborator Author

Background

During consultation of issue 472, participants requested to have EnergyPlanTariffPeriod.demandCharges.days defined as ENUM similar to EnergyPlanTariffPeriod.timeOfUseRates.timeOfUse.days. This would give greater flexibility in representing days the rates are applicable. Further feedback also suggested to align the values of ENUM with banking (for e.g. "MON", "TUE", etc. - see lastWeekDay for example).

There is also an opportunity to align the representation of all days fields within the Energy APIs. More specifically, convert all of them to ENUM type.

Current State

Currently, the following days fields are specified in Energy standards:

1. EnergyPlanSolarFeedInTariff.timeVaryingTariffs.timeVariations

"days": {
    "weekdays": true,
    "weekend": true
}

2. EnergyPlanTariffPeriod.demandCharges.days

"days": {
    "weekdays": true,
    "saturday": true,
    "sunday": true
}

3. EnergyPlanTariffPeriod.timeOfUseRates.timeOfUse

"days": ["SUNDAY", "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "BUSINESS_DAYS"]

Solution Options

The DSB proposes the following options for consideration:

Option 1

Change only the EnergyPlanTariffPeriod.demandCharges.days field type to ENUM as per the original request in CR 472.

Option 2

Extend the change to convert all days fields in Energy schema to ENUMs. This would include the following fields:

  1. EnergyPlanSolarFeedInTariff.timeVaryingTariffs.timeVariations
  2. EnergyPlanTariffPeriod.demandCharges.days
  3. EnergyPlanTariffPeriod.timeOfUseRates.timeOfUse

ENUM Values

The DSB proposes the following ENUM values for days field:

"days": ["SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT", "BUSINESS_DAYS", "WEEKEND", "WEEKDAYS"]

The values of individual days have been aligned to banking sector (e.g. lastWeekDay). The following additional values are proposed for flexibility:

  • WEEKENDS - Saturday and Sunday
  • WEEKDAYS - All days except weekend
  • BUSINESS_DAYS - All days except weekend and public holidays

The values would be applied to all days fields that are currently ENUM, and the ones that will be converted to ENUM as a result of this CR.

The DSB is seeking feedback on the above options and the proposed ENUM values.

@CDR-API-Stream
Copy link
Collaborator Author

Following feedback was received in todays (8th June) maintenance iteration call:

  • Option 2 described in this comment is preferred. This allows for consistency in representation of days across energy APIs.
  • Include PUBLIC_HOLIDAYS in the list of ENUM values, resulting in the below:
"days": ["SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT", "BUSINESS_DAYS", "WEEKEND", "WEEKDAYS", "PUBLIC_HOLIDAYS"]

Any further feedback is welcome.

Note that this CR will be discussed during the Energy specific MI11 call scheduled on the 14th of June.

@perlboy
Copy link

perlboy commented Jun 12, 2022

I think WEEKEND and WEEKDAYS doesn't make a lot of sense as it can already be implied by listing days. Including "helper" expansions may be easier to see for humans but is harder to process for software. We are unlikely to ship WEEKEND and WEEKDAYS to ADRs.

BUSINESS_DAYS and PUBLIC_HOLIDAYS is problematic because locality isn't defined. In what state is this expected to be assessed in?

@CDR-API-Stream
Copy link
Collaborator Author

The DSB has confirmed with EME that their interpretation of BUSINESS_DAYS includes public holidays as it is a shorthand for retailers to express MON to FRI.

Based on this information and feedback received during the Energy MI call on 14th June, the DSB proposes removing WEENEND and WEEKDAYS from the ENUM list. Clarification to the standards will be added stating BUSINESS_DAYS includes public holidays.

Below is the updated structure:

"days": ["SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT", "BUSINESS_DAYS", "PUBLIC_HOLIDAYS"]

If no further feedback is recieved, the DSB will recommend the above change along with Option 2 in this comment to the Chair for approval.

@biza-io
Copy link

biza-io commented Jun 29, 2022

We are unclear why the definition of business days is being redefined based on a historical decision made by a single organisation. New implementers will be required to redefine their understanding of what a business day is.

Additional is unclear how to exclude Public Holidays? By the current definition it is only possible to specify Mon-Fri including public holidays, public holidays or individual days.

Consequently we propose BUSINESS_DAYS excluding Public Holidays and keep PUBLIC_HOLIDAYS to provide the inclusion.

@CDR-API-Stream
Copy link
Collaborator Author

Based on the feedback received in the last MI11 call and comments provided in this thread, WEEKDAYS, WEEKEND and BUSINESS_DAYS will be removed from the list of ENUM for days. The DSB also discussed this proposal with EME team who have agreed to it. Below is the updated ENUM:

"days": ["SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT", "PUBLIC_HOLIDAYS"]

The above change along with Option 2 in this #502 (comment) will be recommended to the Chair for approval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

4 participants