Daylight Savings Times Changes (OS Dependant)

Size: px

Start display at page:

Download "Daylight Savings Times Changes (OS Dependant)"

Barbra Palmer
5 years ago
Views:

1 Daylight Savings Times Changes (OS Dependant) As you may, or may not be aware, a provision of the Energy Policy Act of 2005, extends Daylight Saving Time (DST) by four weeks, beginning in Systems and applications that process dates and times will be affected by this change. IBM AIX: AIX 5.3 AIX 5.2 Technology Level 4 is the minimum level that includes the DST fix, APAR IY Technology Level 8 is the minimum level that includes the DST fix, APAR IY AIX 5.1 (out of support) The update is available as a specific fix by installing APAR IY As an alternative to applying the following fixes you can manually fix the DST files by following these instructions: Setting your DST manually (to be used for out of support versions, such as AIX 4.3.3, or where the customer wants to update the system DST setting without applying any software fixes) You can manually specify when to start and stop DST by setting the TZ environment variable in the /etc/environment file. Examples for the four most common US timezones follows: Timezone Eastern US Central US Mountain US Pacific US TZ Variable Setting TZ=EST5EDT,M3.2.0,M TZ=CST6CDT,M3.2.0,M TZ=MST7MDT,M3.2.0,M TZ=PST8PDT,M3.2.0,M In the TZ variable example above, the first three characters represent the name of the timezone when not observing DST, such as "EST" for "Eastern Standard Time". The first numeral to appear reflects the number of hours behind Coordinated Universal Time (UTC); for example, EST is 5 hours behind UTC. The next three characters represent the name of the timezone when observing DST, such as "EDT" for "Eastern Daylight Time". Following the timezone names is a comma-separated rule for when the location begins and ends observance of DST: "M3.2.0" means to begin observing DST starting in month 3 (March), week 2, and Day 0 (Sunday) = second Sunday in March. "M11.1.0" means to end observing DST on the first Sunday in November. If no DST rules are specified in the TZ variable, then the system will select the rules based on the US defaults. If a DST rule is manually specified, then the system defaults do not get used and the aforementioned APARs become unnecessary. Since no time is specified, the default is 02:00:00 for the time change.

2 These correspond to the new US rules for 2007 and beyond. Once updated, the TZ environment variable will not need to be adjusted again (unless a new law changes the rules). Locations outside the US may need to set the rule to a different month or week number to reflect their own local DST observances. More detail about setting the TZ variable can be found in the "AIX documentation for /etc/environment". NOTE: Reboot the system before March 11, 2007 so all processes running will pick up the new time change. more AIX info found at: SUN Solaris: Solaris Solaris 8, 9, 10 - SunAlert issued SunAlert ( ) - Daylight Saving Time (DST) Changes for Australia (2006), United States (2007) and Others (public) Solaris 2.5.1, 2.6, 7 - DST patches for these releases will be made available through T&M support. Feature Article - Solaris Daylight Saving Time Patch Required See also: Solaris FAQ HP HP-UX: 11i v3: supported, no patch needed. OS Patch ID Document ID PHCO_34266 (superseded by PHCO_34673) i v1 PHCO_34342 (superseded by PHCO_34668) i v2 PHCO_34375 (superseded by PHCO_34669) For other related software such as Java see the following link: SGI IRIX:

3 The IRIX operating system accounts for changes to Daylight Savings Time in accordance with the amendments to the Uniform Time Act. Starting in calendar year 2007, clocks will be set ahead one hour on the second Sunday of March instead of the first Sunday of April. Clocks will be set back one hour on the first Sunday in November rather than the last Sunday of October. Linux: RedHat Enterprise 3 Packages have been released for all three releases of Red Hat Enterprise Linux, and there are a few points in the update that users should be aware of. Resolution: Update the tzdata packages to the following level: tzdata-2005m-1.el3 This was the initial push of this change in tzdata. This includes changes for the US. A caveat of only updating tzdata is there is no built in mechanism to update /etc/localtime to the latest timezone unless the system is already running glibc-common version or greater. If the system is not on these versions, there are additional options: 1. Update both glibc-common and tzdata at the same time in the same up2date run or with the rpm command. This will lay down a new binary from glibc-common called tzdata-update which resides in /usr/sbin. The tzdata package is a requirement of glibc-common, so it will be installed first and will lay down the new tzdata files, then when glibc-common reaches the %post section this is reached: 2. %triggerin common -p /usr/sbin/tzdata-update -- tzdata This will update /etc/localtime accordingly. 3. Update /etc/localtime by hand after installing the latest tzdata package. This can be done with a simple copy command: 4. cp /usr/share/zoneinfo/$current_timezone /etc/localtime where $CURRENT_TIMEZONE is the local timezone (e.g. America/NewYork). 5. Simply re-run redhat-config-time, and save the settings. This will copy over the updated timezone file to /etc/localtime. This is the easiest method, but is troublesome if no X Windows server is running. Once updated, a restart of all the applications relying on /etc/localtime is required. The easiest solution would be to reboot the machine in order to ensure that all the applications are properly updated. Redhat Enterprise 4 Resolution:

4 Update the tzdata packages to the following level: tzdata-2005m-1.el4 This was the initial push of this change in tzdata. This includes changes for the US. A caveat of only updating tzdata is there is no built-in mechanism to update /etc/localtime to the latest timezone unless the system is already running glibc-common version or greater. If the system is not on these versions, there are additional options: 1. Update both glibc-common and tzdata at the same time in the same up2date run or with the rpm command. This will lay down a new binary from glibc-common called tzdata-update which resides in /usr/sbin. The tzdata package is a requirement of glibc-common, so it will be installed first and will lay down the new tzdata files, then when glibc-common reaches the %post section this is reached: 2. %triggerin common -p /usr/sbin/tzdata-update -- tzdata This will update /etc/localtime accordingly. 3. Update /etc/localtime by hand after installing the latest tzdata package. This can be done with a simple copy command: 4. cp /usr/share/zoneinfo/$current_timezone /etc/localtime where $CURRENT_TIMEZONE is the local timezone (e.g. America/NewYork). 5. Simply re-run system-config-date, and save the settings. This will copy over the updated timezone file to /etc/localtime. This is the easiest method, but is troublesome if no X Windows server is running. Once updated, any application relying on /etc/localtime will need to be restarted. The easiest solution would be to reboot the system to ensure that all applications have been updated. Microsoft Windows: The only OS that does not need an update is Microsoft Vista. All other Microsoft OS's will need updates. They can be found at the link above. Also check this link for updates need to other Microsoft software, such as Exchange. NetApp Storage: Any Ontap version prior to needs to be patched , and have all been fixed and do not need to be patched. Check the following link for instructions on how to download the time zone files and install on filer: Cisco: Fixes and commands are included in the links below for each particular version:

5 Cisco Information - Cisco Information (PDF) - Field Notice: FN U.S. Daylight Savings Time Policy Changes Effective March for Cisco IOS Software - 1b.shtml Checkpoint: Please refer to Checkpoint Knowledge base article sk32456 for the information below. SecurePlatform fix for North America Daylight Saving Time (DST) for the 2007 year needs to be installed on the Security gateway. Operating systems take their time from the real-time system clock in the system hardware. DST makes a 1 hour increment or decrement in the real-time clock based on the system calendar. Historically, DST began the first Sunday in April and ended the last Sunday in October. Beginning in 2007, DST changes will be implemented on the second Sunday in March and the first Sunday in November. As a result, the possibility of time-sensitive components of the Security gateway and SmartCenter environment experiencing problems exists and must be prevented. Solution Note: The list of compatible versions is not exhaustive and must be verified off-line before installation in a production environment. Older hardware platforms may not be able to support operating system versions that are compliant with the change in DST and may require replacement. Solaris patches should always be tested in a lab environment for compatibility with the specific build of your Check Point application before deployment in a production system. Incompatibility between Solaris patches and the Check Point kernel module can cause memory trap errors and kernel panics. The following versions of IPSO are certified by Nokia to be compliant with the new DST: 3.8 build build build build all builds all builds

6 The following versions of SecurePlatform are certified by Check Point to be compliant with the new DST: VPN-1/FireWall-1 NG with AI R55 HFA_19 VPN-1 Pro NGX R60 HFA_04 VPN-1 Pro NGX NGX R61 take 56 (dated Aug 2006) VPN-1 Pro NGX R62 The following versions of Crossbeam XOS are certified by Crossbeam Systems to be compliant with the new DST: XOS 7.2 and later. The following versions of Sun Solaris are certified by Sun to be compliant with the new DST: Solaris 8 with patch and or later Solaris 9 with patch and or later Solaris 10 with patch and or later The following versions of Windows operating systems are certified by Microsoft to be compliant with the new DST: Only Windows XP SP2, Windows 2003 Server and Vista versions will be fixed. Windows Update will begin pushing out fixes 1/02/2007. See for more information. The following versions of Red Hat Enterprise Linux are certified by Red Hat to be compliant with the new DST: Red Hat Enterprise versions 2.1 and later are fixed.

7 up2date began pushing out fixes in For systems not subscribing to Red Hat Network, the following fixes must be installed manually: 1. Red Hat Enterprise Linux 2.1 users must update glibc. 2. Red Hat Enterprise Linux 3 and 4 users must update the tzdata package. See for more information. There are several options to resolve the new Daylight Savings Time (DST) issues: 1. Use Coordinated Universal Time (UTC). UTC has no Daylight Savings Time and systems on it are immune to this issue. 2. Upgrade all systems to compliant platforms. 3. Leave systems unchanged and accept log time-stamp errors in SmartView Tracker. Security gateways, SmartCenter servers and VPNs will continue to run uninterrupted even if nothing is done to make the environment compliant. VPNs may be forced to obtain and install new Certificates from the CA server, depending on the expiration time of the existing Certificates, causing brief delays (~4 seconds) in traffic inspection through VPNs. Time stamps on logs in SmartView Tracker may appear to be as much as 23 hours off, but log services use UTC and actual log time stamps are not corrupted by not correcting this problem. Application times can easily be corrected by restarting Check Point daemons on affected systems. On Security gateways and SmartCenter servers, run the cprestart command for VPN-1/FireWall-1 NG AI and VPN-1 Pro NGX. For VPN-1/FireWall-1 NG and earlier, run the cpstop and cpstart commands. Provider-1 servers can be corrected by running the mdsstop and mdsstart commands on the MDS. Note: VPN-1 Edge is not affected by this issue since the logs are already sent in UTC time to SmartCenter and SMP. Related Solution: sk Resolving the issue when the timestamp of the log is off by 23 hours. Applies To: Energy Policy Act of 2005 Daylight Savings Time

8 SmartCenter SmartDashboard SmartView Tracker Logging Time stamp Java: Fixes and commands are included in the links below for each particular version: Additional Information: Any OS or software not found here may be found at the following site:

R ev D. Daylight Saving Time Configuration Guide for an RF Network

R ev D. Daylight Saving Time Configuration Guide for an RF Network 749233 R ev D Daylight Saving Time Configuration Guide for an RF Network Please Read Important Please read this entire guide. If this guide provides installation or operation instructions, give particular