Daylight Savings Time Support
This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST).
All date/times in the system are displayed adjusted for daylight savings time (when in effect). However, not all date/times in the system are stored in daylight savings time:
• Stored in Standard (not adjusted for DST): data that is highly sensitive to DST shifts are stored in standard time without any shifts, this means they have a consistent 24 hour day each day all year and avoid issues that arise from a skipped hour when transitioning to DST and a duplicate hour when transitioning out of DST. For example: initial measurement data, final measurements, device events, TOU map data.
• These date/times are adjusted for daylight savings time prior to being displayed to a user.
• Stored in Legal (adjusted for DST): data that is not as sensitive to DST time shifts are stored in legal time. For example, device configurations, service points, installation events, usage subscriptions, usage transactions.
Adjusting Date/times Upon Receipt
The two largest sources of imported data to the system can be sent in a mixture of date/time formats some in legal time some in standard time:
• Initial Measurement Data
• Device Events
Since both sets of data are sent by head end systems and each head end system handles date/times differently, potentially even differing by device, the interface must be extremely flexible in how it handles date/times. In order to ensure data is accurately stored and processed the system must know how a given meter sends date/time information. This is defined on the device through the Incoming Data Shift field:
• Always in Standard Time: No special handling is required.
• Always in Legal Time: All date/times for the initial measurement data or device event will be converted from legal time into standard time.
• In circumstances where a date/time is received in legal time and it falls on the duplicate hour that occurs when DST ends special logic will be executed to identify whether that hour is the first (still in DST) or second (no longer in DST) of the duplicate hours. If for some reason it cannot be identified which hour it is the transaction will go into error.
Daylight Savings Time Interval Conversion Examples
The following examples show how data received legal time will be shifted into standard time for an interval meter that is read on an hourly basis.
Daylight Savings not in Effect
Date/Time Received in Legal
Date/Time Stored in Standard
01/14/2010 12:00AM
01/14/2010 12:00AM
01/14/2010 1:00AM
01/14/2010 1:00AM
01/14/2010 2:00AM
01/14/2010 2:00AM
01/14/2010 3:00AM
01/14/2010 3:00AM
01/14/2010 4:00AM
01/14/2010 4:00AM
01/14/2010 5:00AM
01/14/2010 5:00AM
Daylight Savings Starts (Spring Forward) - No 2AM interval
Date/Time Received in Legal
Date/Time Stored in Standard
03/14/2010 12:00AM
03/14/2010 12:00AM
03/14/2010 1:00AM
03/14/2010 1:00AM
03/14/2010 3:00AM
03/14/2010 2:00AM
03/14/2010 4:00AM
03/14/2010 3:00AM
03/14/2010 5:00AM
03/14/2010 4:00AM
03/14/2010 6:00AM
03/14/2010 5:00AM
Daylight Savings in Effect
Date/Time Received in Legal
Date/Time Stored in Standard
06/14/2010 12:00AM
06/13/2010 11:00PM
06/14/2010 1:00AM
06/14/2010 12:00AM
06/14/2010 2:00AM
06/14/2010 1:00AM
06/14/2010 3:00AM
06/14/2010 2:00AM
06/14/2010 4:00AM
06/14/2010 3:00AM
06/14/2010 5:00AM
06/14/2010 4:00AM
Daylight Savings Ends (Fallback) - Duplicate 1AM
Date/Time Received in Legal
Date/Time Stored in Standard
11/7/2010 12:00AM
11/6/2010 11:00PM
11/7/2010 1:00AM
11/7/2010 12:00AM
11/7/2010 1:00AM
11/7/2010 100AM
11/7/2010 2:00AM
11/7/2010 2:00AM
11/7/2010 3:00AM
11/7/2010 3:00AM
11/7/2010 4:00AM
11/7/2010 4:00AM
Daylight Savings Impact on Periodic Estimation
In periodic estimation both the interval and scalar versions can be impacted by daylight savings time:
• Interval periodic estimation using the "Predictable Cut-off" method.
• All scalar periodic estimation