[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] Time Zones & time zone changes (a.k.a. DST)
Hi Anders, (All), Two points: 1. From what has been said, it appears to me that there may be a requirement in some cases to have a time zone code available locally in a charge point, such as for the purpose of printing a locally unique/unambiguous time zone indicator (e.g. " "EST") beside timestamps on printed receipts. However, given the variability of such codes, and the local specificity, they should only be seen as a more human friendly optional alternative to the canonical time zone offset (from "system time") in numeric form (+/- hours:minutes). 2. The solution in the (original) OCPP 2.0 draft ( Time[NextTransition] & TimeOffset[NextTransition] ) for specifying changes in local time is generic , to cope with not just "regular" annual daylight saving time shifts, but also any/all other (pre-scheduled) changes in local time (zone) that can occur in various countries from time to time for various reasons. The use of configuration variable name constants that imply that local time changes only twice a year (DST_START_TIME, DST_STOP_TIME, DST_UTC_OFFSET) is insufficiently general and consequently inappropriate. Best Regards, Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie -----Original Message----- From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] On Behalf Of Anders Darander Sent: 09 November 2016 07:06 To: ocpp@lists.oasis-open.org Subject: Re: [ocpp] Re: Old OCPP 2.0 RC2 Time Zones description * Ali Imran Najmi <ali@grid-scape.com> [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 as above. 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). Cheers, Anders > On Tue, Nov 8, 2016 at 2:45 PM Robert de Leeuw > <robert.de.leeuw@ihomer.nl> > wrote: > > 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: robert.de.leeuw@ihomer.nl > > I: http://www.ihomer.nl/ > > 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 * ** *** ** * ** *** ** * ** *** ** *
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]