Description
I think the standard as written today is unable to correctly encode tariff element restrictions that change in the overlap period during change to daylight savings time. Please correct me if I'm wrong!
This may be somewhat related to #495
Picture the following situation, where I want to encode a Tariff that measures Energy and changes every hour on these UTC timestamps:
- 2025-10-25 22:30:00
- 2025-10-25 23:30:00
- 2025-10-26 00:30:00
- 2025-10-26 01:30:00
- 2025-10-26 02:30:00
- 2025-10-26 03:30:00
The Tariff Element Restrictions require me to encode these timestamps in the local timezone of my chargepoint. My chargepoint is in Copenhagen, Timezone: "Europe/Copenhagen".
That lead
5BB7
s to the following encoding in local time:
- 2025-10-25 22:30:00 UTC encodes to local time as: 2025-10-26 00:30:00+02:00 local time part is: 00:30
- 2025-10-25 23:30:00 UTC encodes to local time as: 2025-10-26 01:30:00+02:00 local time part is: 01:30
- 2025-10-26 00:30:00 UTC encodes to local time as: 2025-10-26 02:30:00+02:00 local time part is: 02:30
- 2025-10-26 01:30:00 UTC encodes to local time as: 2025-10-26 02:30:00+01:00 local time part is: 02:30
- 2025-10-26 02:30:00 UTC encodes to local time as: 2025-10-26 03:30:00+01:00 local time part is: 03:30
- 2025-10-26 03:30:00 UTC encodes to local time as: 2025-10-26 04:30:00+01:00 local time part is: 04:30
We see that the local time is not a complete and unique way to specify a point in time on this day even when we specified the timezone of the location.
I propose that the tariff element restrictions are extended to include another pair of fields, perhaps called "start_datetime" "end_datetime" that are specified as complete ISO timestamps including timezone information.