Seasonal Time Shifts
A more common problem related to interval data is the problem of adjusting time for seasonal time changes. Interval data cannot be stored in "legal" time (i.e., in the summer, storing data in daylight savings time or summer time) because the shift from summer time back to standard time causes a duplicate hour. For example, in the United States, the 2 a.m. hour is repeated when shifting from Daylight Savings Time (DST) back to standard time.
To avoid the problem of duplicate records, all data must be stored in standard time. However, when entering and viewing data online, users probably want to see the data in the current "legal" time (i.e., in the summer, data is shown in daylight savings time or summer time).
Logical Time versus Server Time
Fields may be defined as being system date / time stamps or logical data to be captured in standard time.
In the case of interval data:
- Each interval record has a Set Date / Time, which is considered server or physical time and uses the time shift information defined on the base time zone.
- The interval date/time is considered logical time and the time shift information is defined on the related "type" entity for the interval data.
Bill Period and Seasonal Time Shifts
As described in Start and End Times for Billing, the service agreement cutoff time is used to determine the start and end times for billing.
This time is assumed to be in legal time, according to the seasonal time shift linked to the time zone for the service agreement's characteristic premise. It means that when this service agreement is billed, the system adjusts the cutoff time to standard time prior to accessing the appropriate intervals. The diagram below illustrates this point.
Interval Time Display
By default, the system displays interval data in legal time.
- For server related time fields, the time is displayed according to the seasonal time shift record on the base time zone.
- For interval related data, the time is displayed according to the seasonal time shift record on the interval entity's type.
- For the effective date/time links between a service agreement and its interval collections, the time is displayed according to the seasonal time shift record on the SA's characteristic premise's time zone.
A message indicates this to the user, for example, "Date /Time Info is expected in local legal time". The user can opt to change the display to show the data in standard time.
When entering new data, the user is expected to enter data in the same time that is displayed. If the message states that intervals are expected in legal time, the system assumes that the user enters new values in the legal time and converts them to standard time for storing.
If seasonal time shift information is missing for an entity or for the base time zone, data is always displayed and expected in standard time.
Evenly Sized Intervals
As mentioned earlier, the main drive behind shifting data to standard is to counter the effect of missing and duplicate intervals at entry to and exit from a seasonal time shift period. Storing data shifted to standard time ensures all interval records for a given curve are of equal size, which allows for simpler business logic, ignorant of seasonal time shifts considerations.
While this is obvious for hourly or less than an hour interval sizes, we would like to stress that the same concept applies to all interval sizes. If the legal time of an interval shifts during a seasonal time shift you should "counter-shift" it to standard time. If its legal time does not shift year-round, no shifting is needed.
For example, let's assume interval data being recorded in 1440 minute intervals (each read spans a full day).
- If when entering a seasonal time shift period, the legal time for these intervals shifts, say from midnight to 1 am, then when interfaced to the system data should be shifted back to standard to achieve evenly sized intervals.
- However, if the legal time does not shift, i.e. reads are taken at the same legal time, shifting is not applicable. As a matter of fact, shifting in this case causes the stored intervals to be of un-even size, thus complicating the logic that processes the data.
Base Plug-ins. If you decide to configure the system to not follow the evenly sized interval concept described above you may not be able to use the base sample plug-ins and common routines as they assume interval data is stored in evenly sized intervals.
If you are using the interval entities but your interval data have interval sizes larger than hourly (for example, daily), you may decide not to use any seasonal time shift logic. You may set a switch on the installation record to indicate whether or not your interval data should observe seasonal time shifting. Refer to Installation Options - Billing for more information.