OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ocpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ocpp] Re: Old OCPP 2.0 RC2 Time Zones description

In my opinion there is a well working mechanism for time stamps, based on three data fields:

·         Time stamp based on UTC

·         Local offset depending on local time zone

·         Daylight saving offset


The addition of all data fields (based on seconds) is than the local time for the user. In some countries regulations exist, that all time data presented to the end-customer have to be in local time.


For the data representation ISO 8601, RFC 3339 and TZ database could be starting points. But I am not an expert on this.



Kind regards,




Stephan Voit

KnGrid Inc.

65 Enterprise

Aliso Viejo, CA 92656

Mail: svoit@kngrid.com

Phone: +1 (949) 532-9254




On 16-11-08, 16:13, "Anders Darander" <ocpp@lists.oasis-open.org on behalf of anders@chargestorm.se> wrote:


    * Robert de Leeuw <robert.de.leeuw@ihomer.nl> [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 <robert.de.leeuw@ihomer.nl>:


    > > 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







    Anders Darander                 Senior System Architect

    ChargeStorm AB                 Tel: +46 702 44 84 36

    Hospitalsgatan 3      E-mail: anders@chargestorm.se

    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:




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]