Possible Action Required: System time may not change properly at DST start/end dates on AIX 7.1 and AIX 6.1

• Levels affected
• How does this problem affect my applications?
• Recommended actions
• Do I have to reboot?
• Olson time zone format versus POSIX time zone format
• Additional information on AIX levels at risk
• More details

Levels affected

If your country observes Daylight Savings Time, the information in this document may pertain to you. You should read this document carefully to determine if you need to take action.

This problem is exposed on your system if you have both of these underlying conditions:

1. Your system is at one of the affected AIX levels (listed below)
2. Your system is using a POSIX format time zone and the system or an application on the system is using a custom DST setting.

AIX levels affected

The following AIX levels are the only levels affected by this issue. If your system is not at one of these levels, do not take any action.

• 7100-01-03-1207
• 7100-01-02-1150
• 7100-01-01-1141
• 6100-07-03-1207
• 6100-07-02-1150
• 6100-07-01-1141
• >>> 6100-06-07-1207
• 6100-06-06-1140
• >>> 6100-05-08-1207
• 6100-05-07-1140
• 6100-04-11-1140

Determining if you are using the POSIX Time Zone format

If your system is at one of the affected AIX levels, you need to evaluate whether you are using the POSIX time zone format or the Olson time zone format.

POSIX time zone format is the traditionally used format for AIX systems and provides a slight performance advantage over the Olson time zone format. The capability to use the Olson time zone format was initially included with AIX 6.1 in 2007.

If your system is not using POSIX time zone format OR your system is not at one of the affected AIX levels, then your system is not exposed to the problem and you do not need to take action.

To determine if you are using the POSIX time zone format, enter this command:
# echo $TZ

When to take action

If your system is using a custom POSIX time zone format and is at one of the affected AIX levels and you observe a Daylight Savings Time change then you need to take action before your next change.

How does this problem affect my applications?

Applications that are sensitive to time and date information may be negatively affected on AIX systems using the POSIX time zone format. Examples of applications that are time sensitive include SAP and Tivoli Workload Scheduler. The AIX date command is also affected.

If you use Olson time zone format, your applications are not affected. Do not take any action.

Recommended actions

Do one of the following options.

Option 1. Change the time zone to use Olson format

Change the time zone format to use Olson format instead of POSIX format.

You MUST reboot to ensure that applications see the changes, regardless of your AIX level. The changes are stored in /etc/environment and are loaded at boot time. See the man page for the chtz command or use smitty chtz_date. More information about the use of Olson time format is included below

OR

Option 2. Install the appropriate Service Pack

If changing your system to use Olson time zone format is not an option for you, you can install a service pack.

Installing the service pack requires that you reboot. If you have previously installed an iFix for this problem and you choose to install a Service Pack, you will be required to deinstall the iFix first. For instructions on deinstalling an iFix, read Managing Interim Fixes on AIX.

(*) Normal service ended for this level on November 2011. IBM recommends upgrading to a higher AIX 6.1 level or migrating to AIX 7.1.

Do I have to reboot?

Yes. Both the Option 1 and Option 2 require a reboot.

VIOS potential impact is minor

The PowerVM Virtual I/O Server (VIOS) is also affected by this problem but the potential impact is reduced because only VIOS times would be affected.

Olson time zone format versus POSIX time zone format

The TZ environment variable is used to represent time zone information. The value of TZ can be specified in one of the two formats in AIX: POSIX or Olson.

POSIX format specification

The TZ variable specified in POSIX format contains all the information required to identify time zone, specify when to switch DST on and off, and specify the offset from UTC (Universal Time). Note that the system internally does everything in UTC time, and any display of time to the users is a computed offset depending on the time zone and DST rules specified.

The advantage of POSIX is that you can easily and explicitly specify time zone and DST details manually, however you wish. The performance of applications that call time functions will be faster than using Olson specification. And whenever a nation’s government decides to change its DST rules, the POSIX format is simpler because you can simply change the variable definition. There is no need to install of any new patch to update time database files, as Olson requres.

Note: Clients using POSIX time format in regions that do not use the US DST time change will always use Customized override values for Daylight SavingsTime because the default POSIX time zones change DST on the US dates.

A disadvantage with the POSIX is that it cannot track the history of time zone-related changes. When a government changes the rules and you update your TZ variable, it is assumed to be the same DST rule for all years past and future. Another disadvantage is pure readability: Olson uses known names of Cities or Regions, while POSIX format may look cryptic to anyone unfamiliar with it.

Olson format specification

This style of specification overcomes the disadvantages of the POSIX approach. In this method a database is maintained for each time zone, with details of history of time zone and DST changes. You can specify the time zone name in a simple, more human-friendly format, such as “America/Sao_Paulo” rather than specifying the more complex TZ=GRNLNDST3GRNLNDDT,M10.3.0/00:00:00,M2.4.0/00:00:00.

The advantage with this approach is that the time zone name is easy to specify and Olson keeps a history of time zone and DST related changes.

The disadvantage with this approach is that Olson has to load the database file for each time zone specified, and then parse it to find the time zone and DST details. This process can have a modest performance penalty compared to POSIX format . Additionally, when a government changes a time zone or DST rule, a new patch becomes necessary for the Olson time database file.

Olson time zone format has been available in AIX since Version 6.1 in 2007 and has been in use in client environments for many years.

Additional information on AIX levels at risk

To determine if your system is at risk, run the following commands and evaluate the output against the list of affected levels .

lslpp -Ou -qlc bos.rte.date
lslpp -Ou -qlc bos.rte.libc

If any filesets match any of the following levels, you are at risk.

More Details

The problem can be triggered when the rules for DST are specified within the TZ environment variable. Check the TZ variable. If it does not specify the start and stop of DST, then you should not see the issue. Here is an example using the USA Eastern timezone. If the TZ variable looks like this:

$ echo $TZ
EST5EDT

Then you will not go down the code path that produces the issue.

If the TZ variable looks like this (or similar):

$ echo $TZ
EST5EDT,M3.2.0,M11.1.0

Then you can be at risk.

This format, “M3.2.0,M11.1.0”, tells the system to override the default DST rules. The default settings are almost always used in the USA, so most USA systems will not be affected. If the TZ variable overrides the defaults by adding this construct to the TZ variable, then you may see the issue.

In other words, if the TZ variable contains a comma followed by an uppercase M, anywhere within the value, then you are at risk. If not, then you are not at risk. The default TZ variable should be found in the /etc/environment file, although each user on the system can override that variable. One reason to change the variable at a user level may be that the user is working from another location. In rare instances, applications could override the TZ variable and set their own TZ to a custom level.