Daylight savings

#1

How does the platform handle daylight savings and specifically, how does normalizaton address it?

1 Like

#2

See Working with timezones and DST.

C3 folks will correct me if I’m mistaken but what I got from that thread is that “named” timezones (Europe/Paris for instance) that could handle DST are unsupported, at least prior to 7.7. Unless your data is integrated in UTC (in which case timezones & DST don’t matter), you cannot rely on the platform to do any kind of conversion between local times and UTC times and metrics do not handle DST changes.

0 Likes

#3

@udit.garg @lerela Yes the timeZone support for arbitrary zones (apart from NONE / UTC) in evalMetrics / tsEval was added in v7.7

By default the platform operates in mode NONE - i.e. always in logical times, i.e. considers data as loaded. In the NONE mode there will always be 24 hours in a day irrespective of time zone shift or not and the data points will be averaged / filled in with gaps in cases where there are 25 or 23 points during the DST shift. If you do care about preserving the value of the shift and want to work with non 24 hour aligned days, you can explicitly pass the desired zone in which you need the data and platform should do the right thing. I am writing up a doc that will be published in the later versions of the server but here’s the extract:

Topic: TimeZone
Category: Advanced

###Need
A lot of large organizations today have global footprints and have the need to analyze their data in different timezones to make sense of their data at an aggregated level. Imagine an organization having operations in Americas, Europe, Australia, etc wanting to analyze the energy consumption across all of their facilities across the world. In spite of each region generating data in their respective timezones, it still does make sense to analyze this at a broader level to answer questions like “What was the electricity consumption across all my facilities at 2 pm”.

###Solution
Due to the increasing need for these use cases, C3’s time series engine now has the ability to query data in various zones irrespective of where the source of the data comes from. All C3 time series evaluation apis take in a parameter for timezone, which indicates the desired time zone in which the data is desired. The engine figures out the source timezone of the data, converts them to the desired zone & performs time series math on this transformed data.

The following are the supported time zone choices.

#####1. NONE
Creating a datetime in NONE timezone represents that the datetime is in “logical time” i.e. there is no zone information associated with this datetime and means the date and time are as stated by this object. E.g. “2010-01-01T04:00:00” without any zone information means 4 am on the 1st of January, 2010. It doesn’t matter whether this date is being viewed in California or Australia. It will still remain the 1st of January, 2010 4am. This is the default mode for all time series computation.

#####2. UTC
Coordinated Universal Time (UTC) is the basis for civil time today. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth’s rotation (reference : https://www.timeanddate.com/time/aboututc.html)

#####3. OFFSET
One can create dates in specific offsets. These aren’t really time zones but offset from the UTC time. E.g. “2010-01-01T00:00:00-08:00”, the offset will always be 8 hours shifted from the UTC time. The 24 hour time standard is maintained for offset based date times.

#####4. ACTUAL TIMEZONE ID
Create datetime in specific time zone id. E.g “2010-01-01T00:00:00-07:00” (America/Los_Angeles). This datetime will follow the day light savings shifts (may not always have 24 hours in a day) and is in the America/Los_Angeles time zone. “-07:00” happens to be the offset for the “America/Los_Angeles” time zone on the 1st of January, 2010.

###Example
You can now evaluate metrics to return results in any time zone, offset. An example call would look like:

Metric Evaluation in various time zones
1. Organization.evalMetric({
 expression:"ElectricityConsumption",
 id:"MyOrgId",
 start:"2016-01-01"
 end:"2017-01-01"
 interval:"HOUR",
 timeZone: "NONE"
});
//Expected results should be in logical times (no zone) and will always have 24 hours in a day when evaluated at intervals finer or equal to an HOUR
 
2. Organization.evalMetric({
 expression:"ElectricityConsumption",
 id:"MyOrgId",
 start:"2016-01-01"
 end:"2017-01-01"
 interval:"HOUR",
 timeZone: "America/Los_Angeles"
});
//Expected results will be in America/Los_Angeles time zone and could have fewer/more than 24 hours when evaluated at intervals finer or equal to an HOUR
 
3. Organization.evalMetric({
 expression:"ElectricityConsumption",
 id:"MyOrgId",
 start:"2016-01-01"
 end:"2017-01-01"
 interval:"HOUR",
 timeZone: "UTC"
});
//Expected results will be in UTC time zone and will always have 24 hours in a day when evaluated at intervals finer or equal to an HOUR
 
4. Organization.evalMetric({
 expression:"ElectricityConsumption",
 id:"MyOrgId",
 start:"2016-01-01"
 end:"2017-01-01"
 interval:"HOUR",
 timeZone: "+08:00"
})
//Expected results will be in +08:00 offset and will always have 24 hours in a day when evaluated at intervals finer or equal to an HOUR

Checkout the {@link TimeZone} to learn more about generic time zone handling

1 Like