LFS logs and retrieves records based on unadjusted (GMT) store clock (STCK) time. TIMS applications sometimes need to retrieve records from LFS by specifying an explicit local date and time on the retrieval request. If the request is for a date and time in which a different time zone was in effect, the resulting computed GMT STCK for that local date and time will not be the same as the GMT STCK used to log the records, and the wrong records will be retrieved. This is because LFS has no way of knowing that a different GMT offset was in effect for the specified date and time, or what it was, in order to be able to compute the same GMT STCK that was used to log the record. Typically the records actually retrieved would be those an hour before or an hour after the requested time, depending on which way the time zone changed. If TIMS is left up across a time zone change, and the clock is set back an hour, there will be a second set of LFS records corresponding to the same local hour spanned by the reset. In this case, a time based retrieval request for records from that hour would only find the records recorded after the time zone change. If the clock is set forward an hour, there will be no LFS records corresponding to the local hour spanned by the reset. However, in this case, a time based retrieval request for records from that hour would actually find the records recorded the hour before the time zone change. Note that this problem can occur after any time zone change, regardless of whether TIMS was left up or shut down for the clock reset.

All TIMS LFS records contain a GMT STCK field representing the time of the event which generated the record, or some other time that uniquely identifies the record, as well as a GMT offset field representing the GMT offset that was in effect when the record was generated. These fields can subsequently be used to determine the local time of the record or the event that caused the record to be generated. However, many of the TIMS Collection Analysis applications that display LFS records use the current GMT offset instead of the GMT offset from the record to determine local times, resulting in incorrect local times for records that were generated when a different time zone was in effect. Note that this problem can occur after any time zone change, regardless of whether TIMS was left up or shut down for the clock reset.

1. If the user elects to leave TIMS up across a time zone change, the following additional problems can occur. Note that all of the problems listed below can be avoided by taking TIMS down and restarting it after the time zone reset.
2. If the user requests that a Supertrace is to be started when a specific shift is reached, the trace start time may be incorrectly calculated and the trace may be started at the wrong time.
3. If the user issues an exception reload request, the start of the recurring exception cleanup function might be delayed for an hour or as much as 24 hours.
4. If the user has activated Online History collection, new day processing may not occur at the start of a new day. Also, any collection profile that is to be started or stopped based on the time of day may not have these functions occur at the designated times.
5. History Collection Records will not be collected if Maximum Records value is exceeded due to setting the time zone BACK. Also records will not be collected if the local time is now outside of the specified collection range / day due to setting the time zone FORWARD. It should be OK for history collection (with previously noted impacts) if the time zone change spans midnight but it still is not recommended that this be done.
6. History Retrieval Records will not be retrieved if Number of Records value is exceeded due to setting the time zone BACK. Also records will not be retrieved for the time period skipped due to setting the time zone FORWARD (because none where collected for the skipped period). Retrieval and viewing of history records may be confusing for users because the retrieval time is based on the time zone in effect when the history records were GENERATED. For instance, if the system time zone is changed BACK one hour at 2:00 AM (so that the local time is now 1:00 AM) and at 1:05 AM a users views history records he could see records for 1:00-2:00 AM because the time zone used to display the record times is the time zone that was active when the history records where generated (i.e. +1 hour). Likewise the IMS start time for a history record could show a time (apparently) in the future because (again) the time is converted using the time zone in effect when the record was generated.
7. The current GMT offset field (record_prefix.GMTA) that occurs in each TIMS LFS record will not contain the current GMT offset. This field can normally be used in conjunction with any of the GMT STCK fields from the record to determine the local time of the record or the event that caused the record to be generated. The implication is that it will no longer be possible to determine these true local times.
8. Attempting to apply date and time filtering criteria to Collection Analysis screens may not produce the desired results.
9. The TIMS Buffer Analysis, Trans/Class Analysis, and Trans Performance Summary screens will not summarize data and display it properly. These screens may display a different time window or set of time intervals than normal. Also, the values displayed for each interval will not be accurate because it may include data from records that should have been summarized into a different time interval.