|
This worked for us. Sorry for the long message. Gregg In order for DWA to correctly recognize the new DST rules it is necessary that the user's operating system (OS) is updated to the new rules and the Forms6.nsf/Forms7.nsf databases are updated on the Domino server at the same time, or as soon as possible. The Forms file(s) must be updated, even if the user's individual DWA preference for timezone has been set to use the operating system in order to avoid undesired behavior. See section III below for further details. Note: The operating system updates and the Forms updates should be executed within a very short time span of each other. The Forms6.nsf form "qpbase2", and the Forms7.nsf form "qpbase3" must be updated as follows: 1. For Domino 6.x and 7.x open the Forms6.nsf file in Lotus® Domino Designer®, and open the form "qpbase2". 2. Locate each of the following entries (they may not be sequential to each other) and revise the DST parameters for each of them to: 3, 2, 1, 11, 1, 1 Use the Edit > Find menu to locate the entries. Modify the DST parameters only; do not make changes to the labels or descriptions or any other areas of the form. ["Alaskan", "Alaskan", "(GMT-09:00) Alaska", 9, true, " 4, 1, 1, 10, -1, 1 "] ["Pacific", "Pacific", "(GMT-08:00) Pacific Time (US & Canada);Tijuana", 8, true, " 4, 1, 1, 10, -1, 1 "] ["Mountain", "Mountain", "(GMT-07:00) Mountain Time (US & Canada)", 7, true, " 4, 1, 1, 10, -1, 1 "] ["Central", "Central", "(GMT-06:00) Central Time (US & Canada)", 6, true, " 4, 1, 1, 10, -1, 1 "] ["Eastern", "Eastern", "(GMT-05:00) Eastern Time (US & Canada)", 5, true, " 4, 1, 1, 10, -1, 1 "] ["Atlantic", "Atlantic", "(GMT-04:00) Atlantic Time (Canada)", 4, true, " 4, 1, 1, 10, -1, 1 "] ["Newfoundland", "Newfoundland", "(GMT-03:30) Newfoundland", 3003, true, " 4, 1, 1, 10, -1, 1 "] 3. Save the form. 4. If you are running Domino 7.x then repeat the steps above for the Forms 7 .nsf database and the "qpbase 3 " 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 reselect their time zone setting. Note: For users who are in Mexico and use Pactic time, an additional time zone entry will be necessary as they can no longer use the existing Pacific (US & Canada) time zone selection (because it uses different DST rules): a_Table[a_Table.length] = [ "Mexico 3", "Mexico 3", "(GMT-08:00) Tijuana, Baja California", 8, true, "4, 1, 1, 10, -1, 1" ]; Important Note: This technote previously recommended a workaround where additional timezone definitions were added to the "Custom_JS" form. If you have already performed these updates, then it is advised that the updates not be reversed at this time. The following instructions should be followed regardless of whether the earlier workaround was applied. Further instructions on this subject are provided in the section "VI. Workaround Previously in this Technote" below. III. Error: "Your timezone setting is different from your operating system's current one.." The following error message may occur if the operating system's DST rules and DWA Forms DST rules are not in synch. "Your timezone setting is different from your operating system's current one. You can change your timezone setting by going to the Calendar section in the Preferences dialog." This error is an intended warning so that users are aware there is a mismatch between the OS DST rules and the Forms DST rules. Note: The error may also occur in cases where the client OS and Forms have both been updated. In this case, have the user reselect their time zone setting in DWA under Tools > Preferences > Calendar. IV. Behavior that may occur when Forms file has not yet been updated but user's OS has been updated to new DST rules If a user's DWA timezone preference is set to use the OS, the Calendar entries the user creates will have an unexpected timezone label (ZN parameter in the StartTimeZone and EndTimeZone fields); the value will end up being "Unknown1" or "Greenwich". This will result in the Calendar entries appearing in the expected time zone or in Greenwich Mean Time, respectively. After the Forms files have been updated, these Calendar entries will need to be rescheduled so that the ZN parameter is corrected. If a user's DWA timezone preference is set to use a specific time zone then Calendar entries the user creates will have the expected timezone label (ZN parameter in the StartTimeZone and EndTimeZone fields) but unexpected DST rules (in the DL parameter in the StartTimeZone and EndTimeZone fields), and as such will not work properly in all scenarios. The Calendar entries will appear at the proper time when viewed from DWA, but will appear an hour later when viewed from the Notes client. Once the Forms files have been updated, the Calendar entries will then appear an hour later than originally scheduled, and will need to either be manually rescheduled or rescheduled using agents IBM Lotus will be providing. V. Agents to update Calendaring and Scheduling, and Resource Reservation entries For existing Calendar entries occurring March 11, 2007 2:00:00 AM through April 1, 2007 2:00:00 AM , or October 28, 2007 2:00:00 AM through November 4, 2007 2:00:00 AM and for repeating Calendar entries spanning that date, that were created before the fix was applied , the Chair can reschedule the Calendar entries after the fix has been applied. For additional information, refer to the technote "Effects of 2007 Daylight Saving Time (DST) changes on Lotus Notes Calendaring and Scheduling functionality and Resource Reservation functionality" (# 1232652 Link ). Note: Beta versions of the agents are now available (refer to the technote in the previous paragraph). The current beta agent versions may not be fully compatible with Calendar entries created using DWA. Additional enhancements are planned for Calendar entries created in DWA. These enhancements will also include functionality which will reset the timezone text parameter (ZN parameter in the StartTimeZone and EndTimeZone fields) to remove the "2007" suffix when found. The agents will also be enhanced to reset the user's timezone selection as well. VI. Workaround Previously in this Technote - Do Not Use The workaround specified previously in this technote, where the Custom_JS form was updated to include additional 2007 timezone entries, was found to have some undesired effects when used in a mixed Notes and DWA environment. For example, a Calendar entry created in DWA containing the timezone text "Eastern2007" would get revised to "Eastern" if edited or rescheduled from a Notes client. When the same entry was then accessed via DWA it would be recognized as pertaining to the original Eastern DST rules. The added entries within the Custom_JS form, found in the TimeZone_API section of the form, should be retained for compatibility until after the recommended steps above have been executed and the entries have been manually rescheduled or the C&S fix agents have been applied. See the following section for information on the fix agents. For reference, these were the specific steps for the previous workaround. These steps are no longer recommended. However, if you had previously performed these steps, they should not immediately be reversed. 1. Changes need to be made to Forms6.nsf or Forms7.nsf. Domino Web Access has a function, called API_TimeZones() in the Custom_JS form of the Forms nsf file which can be used to add updated time zone and DST information. Using the Domino Designer, open the Forms6.nsf or Forms7.nsf database. Open the Custom_JS form and locate the API_TimeZones() section. This code adds additional selections for the revised 2007 entries into DWA's internal timezone table. The new corrected entries will appear at the top of the drop-down dialog for DWA users under Preferences > Calendar > Time zone. The additional code entries noted below must be located prior to the line "return (a_Table);". Note: Once the new time zone settings are added, the HTTP task will need to be restarted for the new settings to become available. Note: This change should be applied AFTER the first Sunday in November 2006 (November 5, 2006). a_Table[a_Table.length] = [ "Alaskan2007", "Alaskan (2007-)", "(GMT-09:00) Alaska (2007-)", 9, true, "3, 2, 1, 11, 1, 1" ]; a_Table[a_Table.length] = [ "Pacific2007", "Pacific (2007-)", "(GMT-08:00) Pacific Time (US & Canada, 2007-)", 8, true, "3, 2, 1, 11, 1, 1" ]; a_Table[a_Table.length] = [ "Mountain2007", "Mountain (2007-)", "(GMT-07:00) Mountain Time (US & Canada, 2007-)", 7, true, "3, 2, 1, 11, 1, 1" ]; a_Table[a_Table.length] = [ "Central2007", "Central (2007-)", "(GMT-06:00) Central Time (US & Canada, 2007-)", 6, true, "3, 2, 1, 11, 1, 1" ]; a_Table[a_Table.length] = [ "Eastern2007", "Eastern (2007-)", "(GMT-05:00) Eastern Time (US & Canada, 2007-)", 5, true, "3, 2, 1, 11, 1, 1" ]; VII. Background Information More information on the DST 2007 changes can be found in the technote, "Lotus software: United States and parts of Canada extend Daylight Saving Time (DST) in 2007 " ( #1245334 Link ) Some operating systems, such as Windows, that have a single Pacific time zone for portions of Mexico, the United States, and Canada will be making changes. For information on the changes being made see the technote, "Daylight Saving Time 2007 effects on Pacific Mexico - Tijuana and Baja California" (# 1253482 ).
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.