feature request: (note this point is a complement to issue C067)
for the analysis of the data that can be captured via SBFspot
there is a problem to compare data of sequential (groups) of days, this problem is related to switch of system time between "summer-time" and "winter-time"
the cause is: -the actual implementation of SBFspot does not include options about DLS
- the timezone table does not include "DLS-OFF" variants
- there is no option to instruct SBFspot how to handle DLS, actual interpretation -> DLS is allways ON
the minimum extension fits to the condition that:
-AND- system-time -AND- external-time-sources are set to "DLS" = "OFF"
in this minimum extension all time-stamps are handled at "STANDARD-TIME"
depending on the installation and the comm's with PVoutput
various types of additional parameters might be needed
- for instance - assume all system parts follow DLS-time
-- then at export of the data into the tables - the timestamps need to be recalculated to DLS-OFF
RATIONAL: - to analyse/compare the energy production for longer periods, examples
- the effect of shadow and inefficiencies the actual output of SBFspot is difficult to compare for
-- period of ~28feb - ~28march (still WinterTime) with the corresponding (=== sun-evolution)
-- period of ~25oct - ~28sept (still SummerTime)
for all these days the charts for intra-day yield are offset with one hour
- intra-day periods of several years around the DLS switch (in Europe end oktober / end march) !!!
PROPOSAL: "feature request" - complement actual "TimeZone" param. with DLS awareness options
one parameter for basic extension:
- TZ-DLS-Applied=YES|NO (default=YES) time-zone interpretation: -DLS-applic -DLS-not-applic
depending on the needs of SBFspot users (and integration with PVoutput . . .
additional parameters might be needed (examples)
- csv-time-DLS=DLSON|DLSoff (default=DLSON) selects timestamp in Spot-table and daily-table
--- DLSON meaning apply time zone & DLS (if DLS is applicable within the timezone)
--- DLSOFF recalculate timestamp 'inverter' and 'system' in tables such that output allways refers to "Standard time"
for the analysis of the data that can be captured via SBFspot
there is a problem to compare data of sequential (groups) of days, this problem is related to switch of system time between "summer-time" and "winter-time"
the cause is: -the actual implementation of SBFspot does not include options about DLS
- the timezone table does not include "DLS-OFF" variants
- there is no option to instruct SBFspot how to handle DLS, actual interpretation -> DLS is allways ON
the minimum extension fits to the condition that:
-AND- system-time -AND- external-time-sources are set to "DLS" = "OFF"
in this minimum extension all time-stamps are handled at "STANDARD-TIME"
depending on the installation and the comm's with PVoutput
various types of additional parameters might be needed
- for instance - assume all system parts follow DLS-time
-- then at export of the data into the tables - the timestamps need to be recalculated to DLS-OFF
RATIONAL: - to analyse/compare the energy production for longer periods, examples
- the effect of shadow and inefficiencies the actual output of SBFspot is difficult to compare for
-- period of ~28feb - ~28march (still WinterTime) with the corresponding (=== sun-evolution)
-- period of ~25oct - ~28sept (still SummerTime)
for all these days the charts for intra-day yield are offset with one hour
- intra-day periods of several years around the DLS switch (in Europe end oktober / end march) !!!
PROPOSAL: "feature request" - complement actual "TimeZone" param. with DLS awareness options
one parameter for basic extension:
- TZ-DLS-Applied=YES|NO (default=YES) time-zone interpretation: -DLS-applic -DLS-not-applic
depending on the needs of SBFspot users (and integration with PVoutput . . .
additional parameters might be needed (examples)
- csv-time-DLS=DLSON|DLSoff (default=DLSON) selects timestamp in Spot-table and daily-table
--- DLSON meaning apply time zone & DLS (if DLS is applicable within the timezone)
--- DLSOFF recalculate timestamp 'inverter' and 'system' in tables such that output allways refers to "Standard time"