© 2016 IBM Corporation Daylight Saving Time Changes with Server

Daylight Saving Time changes with Server Time Protocol

Preface: Questions come up twice a year regarding how to safely handle daylight saving time (DST) changes. This paper will provide some guidance. It will also describe the three methods available to change your local time due to daylight saving time (DST).

There is reference material available in the Server Time Protocol (STP) Redbooks.

 STP Planning Guide, SG24-7280  STP Implementation Guide, SG24-7281  STP Recovery Guide, SG24-7380 http://www.ibm.com/systems/z/advantages/pso/stp.html

History: For as long as I can remember, IBM mainframes and z/OS (MVS) have had the ability to dynamically change its local time offset. Other IBM operating systems also have this ability, but this Techdoc will focus on just z/OS. Historically, z/OS has had the SET CLOCK command which can be issued while z/OS is running. Issuing this command does not affect the machine or LPAR logical Time of Day (TOD) Clock time. Beginning with z/OS V1.7 a new command was made available for this purpose - SET TIMEZONE={W|E}.hh[.mm].

The TOD Clock has historically represented Greenwich Mean Time (GMT), but with the arrival of the IBM 9037 Sysplex Timer in 1990 and Server Time Protocol in 2006, the TOD Clock represents UTC. Coordinated Universal Time (French: Temps universel coordonné), abbreviated as UTC, is the primary time standard by which the world regulates clocks and time.

Some, but not all, locations around the world change their local time forward or backward due to DST. The actual date and time in which these changes occur depends on laws enacted by various countries, states or locales. In most cases, the jump forward or backward is in an increment of one hour, but that’s not always the case. The jump could be some other value such as 15 or 30 minutes.

Local time is the TOD Clock value with the local time offset applied. The TOD Clock is considered monotonic and never jumps the time as local time can and does. This makes the TOD Clock an excellent tool for measuring elapsed time, whereas local time is not.

Is it Safe?

Regarding safety, dynamically setting the local time forward shouldn’t be an issue, but setting the local time backward causes questions. The concern is always about having repeated timestamps. All major IBM subsystems (DB2, IMS, CICS) are able to handle setting the local time backward without affecting their operations or causing repeated timestamps. Some system logs focus on local time and will thus have repeated timestamps (syslog, logrec, RMF, SMF).

If you have home grown applications, it’s probably a good idea to check whether or not they are using instructions that utilize UTC or a local time offset to obtain the time. Those applications using local time logs may need to be rewritten or shut down for an hour when DST falls back to avoid repeated

timestamps. Of course, there are some applications where you may not care if there are repeated timestamps.

Today’s environment:

Since today most mainframers are (or should be) using Server Time Protocol (STP), the rest of this paper will only focus there.

Remember that STPZONE YES in the CLOCKxx member determines whether or not STP will have an effect on the various LPARs local time. z/OS LPARs with STPZONE NO will not be affected by STP local time offset actions. You may have some LPARs that have been instructed to run in a specific local time zone that’s in a different time zone than the LPARs running with STPZONE YES.

Operationally, there are three choices if using STPZONE YES in the CLOCKxx member of parmlib.

1. Change Immediate is pretty obvious. Choose STD (standard time) or DST (daylight saving time) and click OK. The IBM 9037 Sysplex Time (aka ETR) can also do this. z/OS will immediately jump its local time offset to the new local time. UTC will not be affected.

2. Schedule standard time or daylight saving time: manually select a date/time for the change to take place and click OK. Do this twice a year. The ETR can also do this. At the time and date specified, z/OS will jump its local time offset to the new local time. UTC will not be affected.

3. Automatically Adjust: With STP Auto-Adjust, you inform STP what time zone your mainframes (and z/OS LPARs) are running in. That is, you tell STP you live in "Tokyo" or "New York" for example. STP knows the date and the time when DST is supposed to change based on the laws of that local country or city time zone. Based on those laws, STP will do the adjustment automatically twice a year without any further operator input. UTC will not be affected. ETR cannot do this.

Note that DST laws change. To keep STP accurate and aware of changes to the laws, mainframe maintenance (MCLs) must be kept up to date.