Date Simulator is a tool that alters the results an application or job receives in response to time and date requests. It alters the time and date for specified jobs only. Without Date Simulator, time and date sensitive testing would require resetting the system clock.
The system clock is traditionally set to Universal Time (formerly Greenwich Mean Time). However business applications generally operate using LOCAL TIME. The difference between UTC and LOCAL time is referred to as the TIMEZONE. The z/os MVS system stores the local TIMEZONE in a system field named CVTLDTO (local date time offset). Date Simulator results are dependent on both the system clock and the CVTLDTO values.
The local TIMEZONE is traditionally changed twice per year. In the US, this is referred to as the beginning and end of Daylight Savings Time. In the UK, this is referred to as British Summer Time. Other locations refer to it as summer/winter time.
The source of the local time zone setting is controlled by the SYS1.PARMLIB(CLOCKxx) parameter. There are several methods and utilities that will update the value in CVTLDTO.
In the simplest example ,the time zone value in CVTLDTO is changed with a system operator commands:
SET TIMEZONE=D.HH.MM
When Date Simulator is started (by executing PGM=WARPMAIN) it copies the CVTLDTO value to a CA Date Simulator control block. It does this in an effort to minimize its processing overhead on all time/date request.
If Date Simulator is executing when the local TIMEZONE (ie. CVTLDTO) is changed, Date Simulator must be stopped and restarted to update the copied CVTLDTO value. Failure to do this will result in the time reported by Date Simulator being incorrect.
Date Simulator has a separate component that executes in CICS, named WARPCICS. WARPCICS copies the value from WARPMAIN to local CICS storage when CICS is first started. If CICS is executing when the time zone was changed, then CICS must be restarted after WARPMAIN was restarted.
Given this explanation, the "best practice" after CVTLDTO is changed is: