[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, * Brendan McMahon <Brendan.McMahon@esb.ie> [161109 17:09]: > 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. Well, this is just convenience. However, manually adding a number of transition dates would be troublesome. > 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). I see that most people prefer the (seemingly) easier way to directly add a numeric time offset, combined with the next transition date. My concern is just as much a CP that can be connected to a CS, or be used in a completely stand-alone way. In such a case, assuming that we're not redefining the dayligt saving or modify the timezone in any other way; the use of a timezone will make it easier to handle the changes for a number of year. This is obviously partly outside of the OCPP scope, as the CP easily can get the next transistion time immediately after the last transition if it's connected to a CP. > 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. That looks OK to me. I can personally see advantages with a tzdata approach, but this should be OK. > 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. Sure, the names suggested wasn't really meant to be set in stone, rather to indicate that those dates might be necessary. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]