An additional thought on DST, something I learned during work on WS-Calendar.
There are at least two countries where the date of transition to DST and back is just announced a week or so ahead of time. No pattern. No predictable rule except
And as mentioned by the TC Administrator, Chet, Lord Howe Island which runs on Lord Howe time and only shifts the clocks 30 minutes. (Lord Howe was famous for
always being 1/2 hour late.)
Markets must be on Zulu time, because power must be acquired even on the 25 hour long day. People are on local time, so their schedules are on local time. Many
renewables are, to the extent they are scheduled, on geotime, meaning that the sun shines when it shines even where noon is five hours different than high noon.
Then there is this:
Time Zone Data Distribution Service
Let’s not re-invent RFC 7808.
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Ali Imran Najmi
Sent: Wednesday, November 9, 2016 11:10 AM
Subject: Re: [ocpp] Re: Old OCPP 2.0 RC2 Time Zones description
I agree with Brendan that there needs to be additional date/time info for DST start time and end time, which needs to be passed to the CP for the daylight switching (surely required when offline). The heartbeat is a regular RTC sync as
mentioned in OCPP 1.5 and OCPP 1.6 and thousands of CP sync their clocks from it, the offset and daylight saving date/time start/end is already defined in old OCPP 2.0. Just need to have use cases defined on when this data would be synced.
Yes the daylight saving can be a optional feature which all CP may not support.
TZ data may not be bad altogether but there shouldn't be 2 sources for time and daylight sync to the CP as the two sources can be out of sync as well.
So may be we decide on either below and have use cases defined
a. Remove time sync from OCPP messages and define how to use TZdata in OCPP OR
b. Use offset, dst-offset, dst-starttime, and dst-stoptime as Anders suggested and already present in old OCPP 2.0 under clock component.
* Ali Imran Najmi <firstname.lastname@example.org> [161108 11:07]:
> As I understand the timezone may not be required for the display or
> printed(not seen yet) on CP (as locals know its local time), so we can keep
> it simple by using Offset.
Using a timezone make it easiear for the CP to handle the daylights
saving if it's off-line during that transition. Of course, this would
likely require the tzdata to be updated once in a while, though I'd
guess that most likely, the FW will be updated anyway. Not least as
we're talking about CP's that's possible connected to the Internet, and
thus will require security updates.
> 1. All communications between CP and CS would be in UTC timezone.
> 2. Offset in minutes for display, print receipt etc. This offset can be
> added to the UTC time to display local time. The CS would always know the
> installation and can put correct offset.
Sure, if the TC thinks that a time offset is better, then it'll be a
time offset. Though, I'm not really convinced...
In that case we need a parameter UTC_OFFSET in the form +XX:XX (-XX:XX).
> 3. Daylight can be controlled by the above offset as mentioned by Anders
Here, we'll need three more parameters: DST_UTC_OFFSET of the same form
We also need DST_START_TIME and DST_STOP_TIME, which needs to be a
complete data + time.
These two last parameters are required to handle the DST changes while a
CP is offline.
> This way donot need any TZ data on the embedded systems (Assuming all the
> CP may not have a OS), TZdata can present more complexities. We should have
> simple things in protocol so that all the CP can follow it,
Do you really foresee an OS-less CP that's connected to a backend using
OCPP? (In my experience, the OS-less CP's are normally not connected).
> On Tue, Nov 8, 2016 at 2:45 PM Robert de Leeuw <email@example.com>
> > Hi Anders,
> > Thanks for you input, yes, a timezone should be a setting configured in
> > the charge point.
> > I'm a bit in doubt about using time/zones with names/abbreviations:
> > "There exists no international standard that specifies abbreviations for
> > civil time zones like CET, EST, etc. and sometimes the same abbreviation is
> > even used for two very different time zones. In addition, politicians enjoy
> > modifying the rules for civil time zones, especially for daylight saving
> > times, every few years, so the only really reliable way of describing a
> > local time zone is to specify numerically the difference of local time to
> > UTC. Better use directly UTC as your only time zone where this is possible
> > and then you do not have to worry about time zones and daylight saving time
> > changes at all."
> > Kind regards,
> > Robert de Leeuw
> > IHomer
> > Hoge Ham 85
> > 5104 JC Dongen
> > John F. Kennedylaan 3
> > 5555 XC Valkenswaard
> > T: +31 6 2857 2123
> > E: firstname.lastname@example.org
> > I:
> > 2016-11-08 8:13 GMT+01:00 Anders Darander <email@example.com>:
> > * Robert de Leeuw <firstname.lastname@example.org> [161107 17:23]:
> > > I have not received any remarks on this.
> > > Does that mean you all agree and this can be put into the specification?
> > I completely missed this one..
> > > 2016-10-21 6:59 GMT+02:00 Robert de Leeuw <email@example.com>:
> > > > Hi Bill,
> > > > As promised, hereby the text for Time as defined in the old OCPP 2.0
> > RC2
> > > > document.
> > > > 1.1 Time Zones & Daylight Saving Time 1.1.1 Time Zones
> > > > To improve interoperability between Central Systems and Charge Points
> > all
> > > > time values SHOULD be exchanged as UTC, with the time zone designator
> > ‘Z’,
> > > > as specified by ISO 8601.
> > This is good, standardizing on UTC for all CP <-> Backend communication
> > is really good.
> > > > For the purpose of displaying local time on a charge point’s display,
> > the
> > > > device model’s Clock component supports specifying a time offset
> > between
> > > > Central System time (UTC or otherwise) and local time at the Charge
> > Point.
> > > > 1.1.2 Daylight Saving Time
> > > > To support punctual automated bi-annual changeover between “standard
> > time”
> > > > and “daylight saving time” periods, the device model supports
> > configuration
> > > > values of the Clock component that allow transitions between
> > “standard” and
> > > > “daylight saving” time periods to be automated by specifying a “next”
> > > > transition date-time and a corresponding “next” time offset.
> > Just a question regarding the points above, do we foresee a large number
> > of tiny MCU's with displays in the CP's?
> > If not, I'd be strongly in favour of just using a timezone to handle
> > both the local offset as well as the daylight savings time. We have the
> > tzdata that's widely used in both (larger) embedded systems and other
> > OSes, see eg
> > I think that using a standard timezone definition makes sense; it
> > reduces the complexity of the CPO, especially a CPO that works across
> > timezones.
> > Cheers,
> > Anders
Anders Darander Senior System Architect
ChargeStorm AB Tel: +46 702 44 84 36
Hospitalsgatan 3 E-mail:
602 27 Norrköping Web:
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: