Hi All, I agree that all time zone (offset) information needs to be specified numerically in hours+minutes, as time zone codes are unstable over time. However, the suggestion that “do not need any TZ data on the embedded systems” is not true if there is a requirement for “offline” operation, whether normally, or occasionally, due to communications outages, etc.. In that case a (possibly extended) offline period could happen “on the day”/“at the time” of a shift between “normal” and “daylight saving” time, and it is not practical/scalable to expect a central system to somehow send out a “change effective local time zone offset” command/setting to thousands of connected charge points exactly at the time that “the clocks go back/forward”. The (original) OCPP 2.0 draft proposal allows charge points to declare, through the device model, whether they have a (battery-backed) RTC, and whether they support pre-scheduled, locally implemented, local time offset changes. In such cases, for the Central System to “pre-program” the charge point in advance with the new time zone offset value and the date & time (in “system time”/UTC) at which the new time zone offset comes into effect. Best Regards, Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] On Behalf Of Ali Imran Najmi
Sent: 08 November 2016 10:08
To: Robert de Leeuw; ocpp@lists.oasis-open.org
Subject: Re: [ocpp] Re: Old OCPP 2.0 RC2 Time Zones description 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. 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. 3. Daylight can be controlled by the above offset as mentioned by Anders 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, 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." 2016-11-08 8:13 GMT+01:00 Anders Darander <anders@chargestorm.se>: * 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
timezones.
Cheers,
Anders
--
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
An timpeallacht? - Smaoinigh air sula bpriontáileann tú an r-phost seo.
Please consider the Environment before printing this email.
* ** *** ** * ** *** ** * ** *** ** *
Tá an t-eolas sa ríomhphost seo agus in aon chomhad a ghabhann leis rúnda agus ceaptha le haghaidh úsáide an té nó an aonáin ar seoladh chuige iad agus na húsáide sin amháin.
Is tuairimí nó dearcthaí an údair amháin aon tuairimí nó dearcthaí ann, agus ní gá gurb ionann iad agus tuairimí nó dearcthaí ESB.
Má bhfuair tú an ríomhphost seo trí earráid, ar mhiste leat é sin a chur in iúl don seoltóir.
Scanann ESB ríomhphoist agus ceangaltáin le haghaidh víreas, ach ní ráthaíonn sé go bhfuil ceachtar díobh saor ó víreas agus ní glacann dliteanas ar bith as aon damáiste de dhroim víreas.
https://www.esb.ie/contact
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
Any views or opinions presented are solely those of the author, and do not necessarily represent those of ESB.
If you have received this email in error please notify the sender.
Although ESB scans e-mail and attachments for viruses, it does not guarantee that either is virus-free and accepts no liability for any damage sustained as a result of viruses.
https://www.esb.ie/contact
* ** *** ** * ** *** ** * ** *** ** * |