| | | | Question | This document provides details on the steps necessary to prepare a Lotus Notes® client and Lotus® Domino® server for changes in the Daylight Saving Time (DST) rules, effective 2008, for the eastern Australian states ACT (Canberra), New South Wales (Sydney), and Victoria (Melbourne) as well as South Australia (Adelaide) and Tasmania (Hobart). In 2008, DST will start on the first Sunday in October and end on the first Sunday in April.
| Operating system time zone | User interface description | | AUS Eastern | Canberra, Melbourne, Sydney | | Cen. Australia | Adelaide | | Tasmania | Hobart |
NOTE: The instructions for preparing a Domino server for the changed DST rules are also necessary for Lotus software products that rely on a Domino server, for example, Lotus Enterprise Integrator® (LEI) or Lotus Sametime®.
If a Notes client or Domino server is not actually set to one of the affected time zones, you might still need to update the system. A Notes client should be updated as described in this document to reflect the new DST rules if either of the following are true:
- Users schedule Calendaring and Scheduling entries, Resource Reservation entries, or Notes Date/Time entries using one of the affected time zones.
- Users set their User Preferences to display a secondary time zone in the Calendaring views, where the time zone specified is one of the affected time zones.
In the above scenarios, it is also advisable to update the Domino server's operating system to reflect the revised DST rules. | | | | | Answer |
The following steps should not be initiated until, at the earliest, November 2007. It is important to apply them before 30 March 2008.
1. Operating system
Apply operating system patch(es) to modify the system's DST rules. It is recommended that you follow the installation guidelines provided with the patch. Some operating systems may allow you to directly modify system settings to affect changes in the DST rules.
Important Note: The Notes client or Domino server should be shut down while the operating system patch or update is being applied. Before restarting the Notes client or Domino server, it is important to follow the instructions below in order for Notes and Domino to work as expected. It is suggested that in cases where a patch is being installed using an automatic distribution procedure, the procedure should be designed to instruct users to exit Notes/Domino before the patch is installed, if required the system should be rebooted after the patch is installed, and then Notes/Domino can be restarted. The following undesired behaviors can occur if the above steps are not followed:
- If the Windows operating system is not restarted after the patch is installed, Notes/Domino will return the old time zone information for time zones other than the current time zone.
- There have been reported cases where the Notes time zone setting is set to an unexpected value when the patch has been installed using an automatic distribution rollout while the Notes client is running.
After applying the operating system (OS) patch, some systems may need to be restarted. Refer to the following table based on manufacturer's recommendation:
| IBM AIX or Sun Solaris | You are required to restart the OS. | | Microsoft Windows | You are required to restart the OS. | | Red Hat Linux | It is recommended that you restart the OS. | | i5/OS | An OS restart is not required. |
2. All Notes and Domino - Java/JVM
Java/JVM is updated in Notes/Domino release 8.0.1 and Domino releases 7.0.2 Fix Pack 3 (FP3) and 7.0.3 Fix Pack 1 (FP1).
Workaround
You will want to update the reference tables that Java uses to ensure that Java code and Java applets that reference time zones function as expected. You can use the IBM® Java Time Zone Update Utility (JTZU) tool to do this. For information relating to the JTZU tool, refer to Document #1249964, "Using the IBM Time Zone Update Utility for Java with Lotus software products."
Notes:
- - The 1.3.7g version of the tool introduces revisions for Southern Australia, Tasmania, and the noted Eastern states.
- - The JTZU tool is not applicable for System i. Therefore, i5/OS and OS/400 users will need to update their SDKs and JREs using PTFs when they become available.
3. Additional requirements and steps specific to operating systems
Note that in Notes/Domino 6.0 and later, the notes.ini parameter DSTLaw cannot be used to control the DST rules that Notes/Domino obeys (with the exception of Domino for i5/OS). In these releases, the DST rule functionality works in conjunction with the operating system DST rule settings, and the DSTLaw parameter is reset to the current operating system rules when Domino is started.
Microsoft Windows
On Windows operating systems, be sure that the parameter, "UseNotesTimeZone=1", is either removed from the notes.ini or modified so that the parameter is set to "0" (zero). For details on setting up custom fields in a Desktop Policy, refer to Document #1196837, "Using a Desktop Policy to set notes.ini and Location parameters" .
IBM i5/OS
Domino running on IBM i5/OS (System i) must use DSTLaw in order to properly control the DST rules. The following parameter should be present in the notes.ini for the Domino server:
This requirement may change in later Notes/Domino releases. It is still suggested that you apply any available i5/OS operating system updates for the revised DST rule changes to ensure that the operating systems and other applications function as expected.
Mac client and non-Windows servers Notes Mac client releases 7.0.3 and later are unaffected by time zone revisions, they rely on the operating system for time zone detail.
Non-Windows Domino releases rely on an internal table for time zone detail. This internal table was revised in Domino releases 7.0.2 Fix Pack 3 (FP3), 7.0.3 Fix Pack 1 (FP1), and 8.0.1 to address the time zone revision discussed in this document.
Workaround
Notes Mac client: The Notes Mac client in releases prior to 7.0.3 relies on an internal table for time zone DST rules. Additional functionality was introduced in Notes 6.5.6 and 7.0.2 that allows you to use a supplied text file (Timezones.txt) to add or customize time zone DST rules. The functionality is also available for Notes 6.5.x releases that were updated with the hotfix for SPR# MCMA6JNVG6. Hotfixes are available for download by referring to Document #4014840, "DST 2007 hotfixes for Lotus Notes client on Macintosh" . Once you have modified the Timezones.txt as noted below, you must add the following value to the preferences file: TimeZoneTable=Timezones.txt
Non-Windows Domino: Starting in Domino releases 7.0.3 and 8.0 you can use a text file (Timezones.txt) to add or customize time zone DST rules. This can be used as a workaround as necessary. For this time zone change you would first modify the timezones.txt as noted below in the "How to modify Timezones.txt for current DST revisions" section , and then add the following entry to the notes.ini of the Domino server: TimeZoneTable=<path>Timezones.txt (Note: The server must be shutdown for this modification.)
How to modify Timezones.txt for current DST revisions:
1. Detach the provided Timezones.txt file if you are not already currently using one. Note: It may be possible that a system is already using a Timezones.txt to deal with other DST revisions. In this case, it is important that you modify the file in use rather than overwrite it.
2. Edit the Timezones.txt file, locate the following entry:
"Cen. Australia", 50, 37439, -3009, Y, 10, -1, 1, 3, -1, 1, 0
3. Modify the entry's last parameters:
"10, -1, 1, 3, -1, 1, 0" to: "10, 1, 1, 4, 1, 1, 0"
4. Locate the following entry:
"AUS Eastern", 52, 37441, -10, Y, 10, -1, 1, 3, -1, 1, 0
5. Modify the entry's last parameters:
"10, -1, 1, 3, -1, 1, 0" to: "10, 1, 1, 4, 1, 1, 0"
6. Locate the following entry:
"Tasmania", 59, 37442, -10, Y, 10, 1, 1, 3, -1, 1, 0
7. Modify the entry's last parameters:
"3, -1, 1, 0" to: "4, 1, 1, 0"
8. Save and exit.
4. All Notes clients
After adjusting your operating system and configuring Notes, it will be necessary for users to reset the time zone setting within their calendar preferences. The setting is accessed through the action button, Tools --> Preferences --> Calendar & To Do (tab) --> Scheduling (tab) --> Time Zone (keyword).
NOTE: If the entry reflects "Local Time" it does not need to be reset.
In addition, if you set an optional secondary time zone display for your Calendar views, then this must be re-selected once the operating system and Notes have been updated. The menu selection is File --> Preferences --> User Preferences --> International --> Calendar --> Time Zone.
NOTE: In most cases, the user's Location document setting, "Use operating system's time zone settings", will work as expected whether set to "Yes" or "No". If the value is set to "No" and you experience behavior where the time zone setting reverts to an unexpected value, then check the time zone setting in all of your Location documents to ensure the expected value is populated for all of them.
5. Domino Web Access clients
The Domino Forms8.ntf file that ships with Domino 8.0.1 contains the necessary updates for this revision.
Workaround
The Domino Forms6.nsf and Forms7.nsf databases must be updated to include the revised DST time zone rules. When these become available in a Domino release or update/hotfix, then this document will be updated to detail the availability and download process.
It is recommended that the updates described below be performed as closely as possible to the time when the host client has its operating system updated to the new DST time zone rules.
The Forms6.nsf and/or Forms7.nsf must be updated as follows:
1. Open the specified form in Domino Designer:
-- For Domino 6.0 - 6.5.3 open the Forms6.nsf file, and open the form "qpbase"
-- For Domino 6.5.4/6.0.5 open the Forms6.nsf file, and open the form "qpbase2"
-- For Domino 7.x and 8.0 open the Forms7.nsf file, and open the form "qpbase3"
2. Locate the entries for "Cen. Australia", "AUS Eastern" and "Tasmania" as noted below. Revise the entries as indicated, revising the parameters from "10, -1, 1, 3, -1, 1" to "10, 1, 1, 4, 1, 1".
Initial entries:
["Cen. Australia", "Cen. Australia", "(GMT+09:30) Adelaide", -3009, true, "10, -1, 1, 3, -1, 1"]
["AUS Eastern", "AUS Eastern", "(GMT+10:00) Canberra, Melbourne, Sydney", -10, true, "10, -1, 1, 3, -1, 1"]
["Tasmania", "Tasmania", "(GMT+10:00) Hobart", -10, true, "10, 1, 1, 3, -1, 1"]
Updated entries:
["Cen. Australia", "Cen. Australia", "(GMT+09:30) Adelaide", -3009, true, "10, 1, 1, 4, 1, 1"]
["AUS Eastern", "AUS Eastern", "(GMT+10:00) Canberra, Melbourne, Sydney", -10, true, "10, 1, 1, 4, 1, 1"]
["Tasmania", "Tasmania", "(GMT+10:00) Hobart", -10, true, "10, 1, 1, 4, 1, 1"]
Note:
-- Use the Edit --> Find menu to locate the entry. Modify the DST parameters only; do not make changes to the labels or descriptions or any other areas of the form.
-- Take care to replace the entry as indicated. Do not add or remove spaces. The entry should have a single space following each comma.
3. Save the form.
4. If you are running Domino 7.x, or 8.0 and you have users with mail files based on the 6.x DWA template, then you must repeat the steps above for the Forms6.nsf database and the "qpbase2" form.
5. Exit Domino Designer.
6. Restart the HTTP task on the server using the console command: tell http restart.
NOTE: It should not be necessary for users to re-select their time zone setting in the calendar preferences of their mail file. If unexpected behavior occurs, then have the user check their time zone settings.
Systems updated to the new Daylight Saving Time rules
Any calendar entry that falls within the extended Daylight Saving Time (DST) period created before the application of the extended DST rules (by the necessary operating system or related Notes/Domino hotfixes) will appear an hour later than originally scheduled.
An additional issue exists specific to Notes 8.0 (Standard Configuration) with a mail8.ntf design. You may observe that calendar entries appear off by an hour. This may happen with all of the Notes/Domino 8.X mail design's calendar views. For additional details, refer to the following document: "Calendar entries appear off by an hour when using Notes 8 (Standard Configuration)" (# 1286434)
Actions to take
First, update your Notes client and Domino servers as noted above to apply the changed DST rules. The sooner this is accomplished, the fewer entries will need to be updated after the operating system DST patch is in place.
Once the systems have been updated you will want to reschedule the affected calendar entries. Entries can either be manually rescheduled, or rescheduled using agents IBM provides.
How to manually reschedule Calendaring and Scheduling or Resource Reservation entries
It is possible to highlight an entry and reschedule it manually using the action button Owner Actions --> Reschedule.
Agents to assist with making updates to Calendar entries and Resource Reservations
IBM Lotus software has prepared a set of LotusScript agents that will update any existing Notes calendar entries and resource reservations to conform to the new DST rules. These agents provide an IT organization flexibility on how to roll-out these updates. They will work on Notes 6.x and Notes 7.x template-based databases by default, with optional support for documents created using a Notes 5.x template.
The following document contains the agents, operating instructions, and specific details on the agents function: "Agents for updating Calendaring and Scheduling entries and Resource Reservation entries for Eastern/Southern Australia as well as Tasmania for Daylight Saving Time (DST) 2008" (# 1283697)
Note: The following document describes issues that are applicable to the noted revised Australia time zones, but the date references and steps to follow are relative to US/Canada. The document may still be helpful to understanding related calendaring issues in greater detail than can be found elsewhere.
-- Document #1232652 - "Effects of 2007 Daylight Saving Time (DST) changes on Lotus Notes Calendaring and Scheduling functionality and Resource Reservation functionality"
Note: The following issues will not occur on Domino server releases 7.0.3 or 8.0 which have been set to use the Timezones.txt file (as instructed above) to revise the relevant time zone table entries. The following issues are covered SPR# SVRO78PSNU; which is fixed in Domino releases 7.0.2 Fix Pack 3 (FP3), Domino 6.5.6 Fix Pack 3 (FP3), and 8.0.1.
Fix details: SPR# SVRO78PSNU
Domino - All Platforms
1. A Domino-generated cookie based on $Preferences has old time zone and DST rules
The Domino $Preferences Web page that creates a Domino-generated cookie does not have the current time zone tables for revised DST rules. This page is used in custom Web applications that parse the cookie. It is also used by Lotus QuickPlace® if users choose the option to display times in a different time zone from the server. For additional reference see Document #1256236, "$Preferences does not contain DST2007 choices in QuickPlace" . Based on SPR# MKIN79ERSB, this issue is corrected in Domino 7.0.3 Fix Pack 1 (FP1) and Domino 6.5.6 Fix Pack 3 (FP3) for the Windows platform. The fix makes Domino, on the Windows platform, dependent on the operating system for this detail.
Fix details: SPR# MKIN79ERSB
Background: Domino Web servers allow you to access a URL that will generate and store a cookie on user browsers with regional and time zone settings. This cookie can then be leveraged in Web applications or JavaScript in order to display or act on data according to time zone/regional settings stored in the cookie. With the DST 2007 patches from Microsoft, a number of new time zones have been created that now observe different DST rules. For example, Pacific and Tijuana have split because Tijuana observes DST at a different time from Pacific. The HTTP Web server shows only the old "Pacific and Tijuana" time zone rule, even after the OS patch is applied to the server and client.
Non-Windows Platforms
2. @GetCurrentTimezone returns old DST rules
When the @GetCurrentTimezone @function is executed using a background agent or in a Web application on a non-Windows server or from a Linux client locally, the function will return the old DST rules. Execution by a Windows client when the database simply resides on a non-Windows server is not impacted.
3. Outbound iCal entries might have start and end times that are an hour too early
The SMTP server that does the MIME conversion will reference the internal time zone table with old DST rules, which sets the start and end times of the meeting so it is an hour too early for the shifted DST weeks. The issue does not occur if the MIME conversion was handled by a Windows client or server.
4. Calendar entries accessed using POP/IMAP will appear an hour too early. The same issue that affects the MIME conversion also affects the POP3/IMAP tasks.
5. Calendar entries created using WebMail will appear an hour too early
The WebMail functionality relies on the @Function @GetCurrentTimeZone to populate a number of fields. As noted above in point #1, this function relies on an internal table and thus functionality based on it will return values that appear an hour earlier than expected.
Below are the places the @GetCurrentTimeZone function is used in the WebMail design:
- View: "($Calendar)" - In Script
- Form: "(Notice)" - In the field: LocalTimeZone
- Form: "_Calendar Entry" - In the fields: LocalTimeZone, tmpShowTZ, StartTimeZone, EndTimeZone
- Subform: "(CSMeetingInterval)" - In the fields: StartTimeZone, EndTimeZone
- Script Library: CSUIViewClass
- Agent: "(MailPolicy)"
6. Linux® 7.0.1 client
The Linux client relies on an internal time zone table for DST rules. This means that C&S entries that fall within the shifted weeks of DST will appear an hour later than expected on non-Linux clients. These entries are correctable by the DST fix agents but the resulting entry will appear an hour too early to Linux clients and correct for non-Linux clients. Other date/time values will also be off by an hour, stored with the incorrect DST rules. For example, converting to MIME from a Linux client is also expected to be affected. There are no current plans to provide a Fix Pack to revise the table for the 7.0.1 Linux client. As a workaround, use the Notes 8.0 Linux client (when available).
- Date/Time fields in custom applications can be affected by the revised DST rules. The agents that IBM Lotus has provided to assist in the revision of Date/Time values in mail databases (Calendaring and Scheduling entries) and in Resource Reservation databases are specific to those applications and document types. The agents do not affect Date/Time values that may be affected in custom applications. For additional detail on this subject as well as a sample LotusScript agent that can be used as a starting point for a solution to revise affected Date/Time fields, refer to Document #1249177, "Daylight Saving Time (DST) 2007 effects on Date/Time fields in Lotus Notes and Domino" .
- Scheduled agents and tasks execute an hour later than expected on the first day of Daylight Saving Time (DST), Document #1256479 .
- Meeting times are off by one hour in Two Day and One Work Week views during the first weekend/week of Daylight Saving Time, Document #1167716
|
| 23 April 2008 | Added detail on additional fixes for SPRs SVRO78PSNU and MKIN79ERSB. | | 20 March 2008 | Added detail about 7.0.3 FP1 fix for particular $Pref issue on Win32. Added 7.0.3 FP1 fix info for Java and for non-windows issues. | | 22 February 2008 | Added various fix details. | | 15 February 2008 | Added link to fix agents. | | 13 February 2008 | Detailed non-Windows Domino internal table is revised in 7.0.2 FP3 and 8.0.1. | | 06 November 2007 | Removed "Brazil" reference | | 20 October 2007 | Initial publication. | | | | | |
