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] Time Zones & time zone changes (a.k.a. DST)


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


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]