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:
I: http://www.ihomer.nl/
2016-11-08 8:13 GMT+01:00 Anders Darander <>:
* Robert de Leeuw <> [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 <>:
> > 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 https://www.iana.org/time-zones.
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: www.chargestorm.se
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
