Novell is now a part of Micro Focus

GroupWise and Daylight Saving Time

Articles and Tips: article

01 Oct 1999


If your company spans more than one time zone, you may run up against some issues with GroupWise and Daylight Saving Time (DST). This AppNote explains what these issues are and how to fix DST-related problems.

Introduction

GroupWise has always been carefully designed to recognize a basic principle of electronic communication: time is relative to the location where that communication may occur. Although the time of day varies throughout the world at any given moment, a responsible network messaging system will reconcile those differences in message time stamps and scheduled appointments. The more widespread the communication, the greater the responsibility of the messaging technology to keep the communication synchronized and useful to those who must deal with time differences.

With this premise in mind, GroupWise engineers designed GroupWise to account for and synchronize messages not only by using the finite standards of the defined world time zones, but also by using the more unevenly applied standard known as Daylight Saving Time (DST).

The purpose of this document is to briefly explain the concepts of world time zones and the application of DST, how DST is handled with different versions of GroupWise (4.x and 5.x), and ways to recognize and correct possible DST problems in GroupWise. The information is included in the following sections:

  • Time Zone and Daylight Saving Time concepts

  • Recognizing DST issues in versions of GroupWise

  • Troubleshooting and resolving 5.x DST problems

  • When to correct DST problems

For more information, refer to the online "GroupWise and Daylight Saving Time" document at:

http://www.novell.com/products/groupwise/administration/gwdaylt0.html

Time Zone and Daylight Saving Time Concepts

The earth's rotation from daylight to darkness and the need for constant communication between different locations in the world make it necessary to establish a system for measuring time based on a single standard. This standard, called Coordinated Universal Time or UTC, is a measurement of mean solar time beginning at a defined longitude on the earth (0°or the prime meridian).

From this longitude, traveling both east and west, timekeepers divide the earth into 24 increments of 15° longitude each. Each of these increments represents a different °standard° time zone and is numbered relative to the prime meridian by adding or subtracting one hour. Thus each time zone is referred to by its offset from UTC. Accordingly, the world time zones are designated from -12 through 0 (UTC) to +12.

Note: UTC time designations are also referred to as Greenwich Mean Time (GMT), so named because authorities at the Greenwich observatory in England established it as the location of the prime meridian.

Daylight Saving Time is the system of setting clocks one or two hours ahead of standard time so that sunrise and sunset occur at a later hour, thus artificially moving a period of daylight to the evening hours. For example, in the northern hemisphere, clocks are usually set ahead one hour in the spring and back to standard time in the fall. When DST is in effect in the southern hemisphere, it is not in effect in the northern hemisphere, and vice versa.

DST is a political system, rather than a scientific one, because national and regional governments decide whether or not they will adopt the system. In some time zones, DST may not be used at all.

Governments or institutions may define the DST starting and ending dates years in advance, but they may also change these dates at any time. For example, in 1996, most of Europe adopted a new DST standard end date setting of the last Sunday of October. Many of the countries agreeing to the change had formerly ended DST on the last Sunday of September.

Because of the lack of consistent DST adoption by the world's governments, the total number of times-of-day within all time zones adds up to about 50.

Recognizing DST Issues in Versions of GroupWise

The constant variability in the adoption of Daylight Saving Time, the improving technology and design of GroupWise, and the need for backward compatibility have uncovered some important issues regarding GroupWise and DST. Because different versions of GroupWise deal with DST configuration in different ways, and because DST is now implemented differently worldwide than it was when older versions of GroupWise were designed, you may see evidence that GroupWise is not handling time-related information correctly. For example, your users may report any of the following problems:

  • Meetings are scheduled to start one hour earlier or later than the sender specified.

  • Incoming messages show an incorrect delivery time.

  • Status of outgoing messages shows incorrect send or receive times.

These symptoms are a result of DST start and end dates being incorrectly calculated. Most commonly, this occurs because:

  • The 5.x system or part of the 5.x system was migrated from GroupWise 4.1 with GroupWise 5.2 Support Pack 2 or earlier code.

  • The original 4.1 system that was migrated to 5.x did not use Daylight Saving Time. That is, the DST clock change settings for the affected time zones were set at 0. (For more information on this scenario, see "DST Reactivated in a 5.x System Migrated from 4.1" later in this AppNote.)

  • Some of the post offices (either in 4.x or 5.x) used incorrect DST settings.

This section of the document discusses the most common GroupWise DST issues and offers possible solutions. The information is organized according to the version of GroupWise you have. This section also includes information about rarely-occurring circumstances that can cause DST miscalculation.

DST Issues in GroupWise 4.x

In GroupWise 4.1, appointments are stored and displayed relative to Greenwich Mean Time. The relationship between the appointment time and GMT is expressed as an offset from GMT. The offset is directly affected by the domain and post office time zone and DST settings you configure in the GroupWise 4.1 administration program, AD.EXE.

If you make changes to these settings while the GroupWise system is in use, those changes are replicated throughout the system. For example, if you change the DST offset after an appointment has already been stored, that appointment will be displayed using a different offset than was in effect when it was stored. Because of this, the following precautions are recommended:

  • Always change the DST settings, including offset, beginning date, and ending date, well before the time when users may set appointments to occur inside the DST observance period. If some advance appointments are already set to occur during that period, all such appointments will be "bumped" by one hour.

  • Always be sure of the DST-observance or non-observance at every physical location where a GroupWise 4.1 domain or post office resides. If one of these objects is physically located in an area that does not implement DST, while other objects in the same GroupWise system are physically located in areas that do, the non-DST object must not be assigned the same time zone as the DST objects. If all objects are assigned the same time zone, AD.EXE assumes that DST settings apply to all objects which share the same time zone, and so it replicates DST settings throughout the system. Obviously, this makes the appointments in non-DST user mailboxes inaccurate.

    For example, the state of Arizona does not observe DST. From a DST point of view, Arizona is logically located in Mountain Standard Time for part of the year, and Pacific Daylight Time for the remainder of the year. If a company had domains in Los Angeles, Phoenix, and Denver, the administrator would assign a different time zone for each domain, making sure that the DST setting was correct for each time zone. Then, in January, a user in Los Angeles could schedule users in Phoenix and Denver for a July conference call and all participants would display that appointment at the appropriate time. However, if the administrator assigned the same time zone to the Phoenix domain as the Denver domain, or to the same time zone as the Los Angeles domain, the move to DST would bump all Phoenix domain appointments previously scheduled during DST.

It is possible that the DST setting for a 4.x domain and the DST setting for a 4.1 post office may not be the same, even when they share the same time zone. If this condition exists and appointments have already been set, correcting the DST offset at a domain incorrectly bumps appointments in all other domains in that time zone. This may occur if routine database synchronization is interrupted, such as when the GroupWise 4.x Administration Server is not running or the target database is damaged.

Resolving 4.x DST Problems. If you detect a DST synchronization problem after appointments have been scheduled to occur during DST observance, there are three solutions:

  • Remove the offset that originally caused the appointments to be bumped. This solution corrects the display problems within the domain but leaves the domain's DST setting unsynchronized with the rest of the system.

  • Reschedule the appointments. This may be difficult if the start and end dates of DST will change for the coming year. For GroupWise 4.1 user instructions on using the client to locate sent appointments, see "Appendix F: Reschedule Multiple Outbound Appointments" in the online GroupWise and Daylight Saving Time administration guide.

  • Run the GroupWise 4.x Appointment Time Adjuster to modify the appointments in a 4.x post office. For more information, see "Using the GroupWise Appointment Time Adjuster" later in this AppNote.

Other Important GroupWise 4.x DST Facts. There are a few other DST-related facts that GroupWise 4.1 administrators should be aware of.

  • If you schedule an appointment on the day (and possibly the day after) that DST goes into effect, that appointment will be stored correctly but displayed incorrectly. There will be a one hour difference. This is a GroupWise 4.x architectural limitation and cannot be corrected.

  • GroupWise 4.x does not allow DST offsets of less than 1 hour (as allowed, for example, in Newfoundland). This is a GroupWise 4.x architectural limitation and cannot be fixed.

  • Remember to change the DST begin date and the Standard Time begin date for DST-affected time zones in GroupWise 4.1 as the calendar dates change each year for these settings.

  • The GroupWise 4.x Appointment Time Adjuster can help you modify existing, future appointments residing in GroupWise 4.x post offices.

DST Issues in GroupWise 5.x

Although improvements have been made in GroupWise 5.x with regard to Daylight Saving Time, some issues still exist if newer GroupWise 5.x code communicates with 4.x or older 5.x code. This section discusses some of the causes of DST problems in GroupWise 5.x, including the specific problems that occur when DST is reactivated in a 5.x system migrated from 4.1.

General Causes of DST Problems. Prior to the release of GroupWise 5.2, time zone information (that is, local UTC) had to be defined for domains and post offices using absolute, preset dates for Daylight Saving Time changes. Later, when the GroupWise 5.2 32-bit client was introduced, a more robust, formula-based DST definition was implemented.

Still later, with the release of GroupWise 5.2 Support Pack 3 (SP3), this formula-based definition was extended to all GroupWise 5.2 components (including the 16-bit client). To maintain backward compatibility and version connectivity, GroupWise 5.2 domain and post office databases were also designed to store GroupWise 4.x post office and gateway time zone definitions that continue to use absolute DST information.

These differences in time zone reckoning can be represented in two groups:

  • Group A—the —absolute date— time zone configuration group, which includes:

    • All GroupWise 4.x components

    • All GroupWise 5.0 components

    • All GroupWise 5.1 components

    • The GroupWise 5.2 16-bit client released prior to SP3

      If you previously elected to disable DST or to edit a Time Zone definition in GroupWise 4.x, these settings will be lost during a migration to GroupWise 5.2. You can easily restore the settings if SP3 has been applied.

  • Group B—the —formula-based— time configuration group, which includes:

    • The GroupWise 5.2 32-bit client

    • The GroupWise 5.2 16-bit client (after SP3 has been applied)

    • The GroupWise 5.5 16-bit client

    • The GroupWise 5.5 32-bit client

If these two component groups communicate using the same GroupWise systems (usually after a 4.1 migration), symptoms of incorrect DST information sharing may occur, including:

  • Differences in appointment times between 5.x and 4.x users

  • Incorrect time stamps on messages processed by gateways

  • Incorrect DST start and end dates for 4.x users.

DST Reactivated in a 5.x System Migrated from 4.1

If you are experiencing appointment synchronization problems in a GroupWise system that was recently migrated to GroupWise 5.x from GroupWise 4.1, it may be because the administrator of the 4.1 system set the DST clock change settings of particular time zone to zero. This deactivates the observance of DST in that time zone by GroupWise 4.1. However, when the GroupWise 4.1 system is migrated, GroupWise 5.2 (with SP3) or GroupWise 5.5 apply their own default time zone definitions to domains and post offices, so DST is reactivated. In this way, depending on the time of year you migrate your post offices and the scheduled dates of the appointments in those post offices, appointment times will be incorrect:

  • If you migrate a post office while DST is in effect for a DST time zone, the appointments for users in that time zone are moved forward one hour on the GroupWise Calendar. For example, an appointment scheduled for 2:00 p.m. is moved to 3:00 p.m.

  • If you migrate a post office while DST is not in effect for a DST time zone, the appointments for users in that time zone scheduled to occur when DST is in effect are also be moved forward one hour on the GroupWise Calendar. Appointments scheduled to occur during non-DST are unaffected.

For more information about adjusting the appointment times that were changed during migration to GroupWise 5.2 (with SP3 applied) or to GroupWise 5.5, see "Recheck the Appointment Times" later in this AppNote.

If the GroupWise 4.1 system was migrated to a GroupWise 5.x system before SP3 was applied, you may have manually deactivated DST settings in order to avoid appointment synchronization problems. If you apply SP3 to the system now, you can reactivate DST for the post offices in time zones where it had been deactivated. After you apply SP3 and correct the DST settings, perform the following tasks on a day when DST is no longer in effect:

  • Run the GroupWise 5.x Appointment Time Adjuster on each 5.x post office to move all appointments between April 5 and October 25, 1998 to one hour earlier.

  • Run the GroupWise 5.x Appointment Time Adjuster on each 5.x post office to move all appointments occurring during the 1999 DST observance to one hour earlier.

  • Run the GroupWise 5.x Appointment Time Adjuster on each 5.x post office to move all appointments occurring during the 2000 DST observance to one hour earlier.

Unusual DST Problems

This section describes two highly unusual circumstances which, when combined with Daylight Saving Time and GroupWise 4.1 migration, cause incorrect DST calculation.

Newfoundland, Canada and DST. This problem occurs when appointments are sent from or received at Newfoundland, Canada. You may notice that appointments sent to the Newfoundland time zone (NFT) from another time zone are scheduled 4 hours, 16 minutes late when DST is not in effect or 3 hours late when DST is in effect. Appointments received from NFT are scheduled 4 hours early when DST is not in effect or 3 hours early when DST is in effect.

This problem affects any time zone that is designated with a negative GMT offset and uses a DST change of less than 60 minutes. The Newfoundland time zone is currently the only time zone that meets these criteria.

You can correct the NFT problem by applying GroupWise 5.2 Support Pack 3. However, if you are a GroupWise system administrator residing in Newfoundland, you will need to use the GroupWise 5.x Appointment Time Adjuster before you apply Support Pack 3. Use the adjuster to modify future appointments scheduled outside of Newfoundland.

"Beep On Errors" Option Set in GroupWise 4.1. In GroupWise 4.1, the system administrator has the option of setting the administrative environment options. This is done by selecting File | Setup | Environment. One of the options, Beep On Errors, can be locked so that 4.1 client users will always receive a beep if an error is detected.

In GroupWise 5.x, this particular setup option was not implemented, but the code record for the option was reused for 5.x DST calculation. This means that if a 4.1 system with this locked record left intact is migrated to GroupWise 5.1 or GroupWise 5.2 (prior to Support Pack 3), the time zone record is migrated to 5.x DST calculation methods, but it cannot be unlocked. The end result is an inability to correct DST settings from a migrated 4.1 system.

To correct the problem, make sure that you apply the GroupWise Support Pack 3 to the 5.x system you are using during the migration. After you do this, you can change or adjust the DST settings as necessary.

Troubleshooting and Resolving DST Problems in GroupWise 5.x

If you suspect that DST synchronization is the cause of incorrect appointments in your users' mailboxes, you need to troubleshoot to find the best way to correct the problem. The flowchart or "decision tree" diagram in Figure 1 will help you decide which troubleshooting strategy you can take to remedy these symptoms at your 5.x primary domain.

Figure 1: DST troubleshooting flowchart.

Using the GroupWise Diagnostics to Check DST Settings

The GroupWise 4.x, 5.0, and 5.2 16-bit clients depend on the Daylight Saving Time settings made in AD.EXE or in NetWare Administrator and saved in the domain database. The settings are made when you install or create a new domain or post office, or you can change them with the Time Zone configuration tool found in GroupWise System | Operations.

The settings required for DST adjustment vary according to the version of GroupWise. If you have migrated part or all of your GroupWise 5.x system from GroupWise 4.x, the only way to check all of the current stored DST values in a domain database is by using the GroupWise Diagnostics menu, which adds diagnostic functionality to the GroupWise DLLs "snapped in" to NetWare Administrator during a GroupWise 5.x installation. Although this tool is also included in the installation, it is not readily available (or visible) until you add its string value to the Windows Registry.

When you enable the GroupWise Diagnostics menu, you can check a time zone record stored in a domain database to see if the current values for its Daylight Saving Time settings are correct. (For details about enabling the menu and checking these values, see "Appendix B: The GroupWise Diagnostics Menu and Time Zone Settings" in the online GroupWise and Daylight Saving Time administration guide.)

After you use the GroupWise Diagnostics menu to check the settings, you should be able to determine whether these settings are correct or incorrect.

If DST Values Are Correct. If the DST values appear to be correct when you view them using the GroupWise Diagnostics menu and your users are experiencing appointment problems or their messages have an incorrect delivery time stamp, Daylight Saving Time has probably been configured incorrectly at some domain or post office.

To correct the misconfiguration, use the Time Zone configuration tool to check the following:

  • Each Time Zone assigned to a domain or post office in your system must be set to the correct GMT offset.

  • The Daylight Saving Time begin and end dates must be set correctly for each time zone used by a domain or post office in your system.

  • The file server where a domain, a post office, a gateway, or an agent is operating must be configured with the correct time and DST settings.

If DST Values Are Not Correct. If the DST values appear to be incorrect when you view them using the GroupWise Diagnostics menu and your users are experiencing appointment problems or their messages have an incorrect delivery time stamp, you should do two things:

  • Apply the GroupWise 5.2 Support Pack 3. Some basic Daylight Saving Time problems that occurred in earlier versions of GroupWise, particularly with the 16-bit client, were corrected with the GroupWise Support Pack 3 (SP3). If DST values appear to be incorrect when you view them in GroupWise Diagnostics, the first thing you do is apply SP3. With the new, more robust, formula-based DST definition that originated with the 5.2 release and other DST fixes, SP3 is an excellent method to use for correcting DST problems in your GroupWise 5.2 system.

    When you apply SP3, you should update all of your GroupWise 5.2 components, including the GroupWise Administrator DLLs, the GroupWise client, and the GroupWise agents. The SP3 process requires that you update the Admin DLLs on at least one server; however, if other servers on your network store a copy of the GroupWise Admin DLLs, each of these will need to have their SYS:\PUBLIC directory updated with the SP3 process. All GroupWise administrators on your system must be using the same revision (that is, the same 5.2 Support Pack) of the Admin DLLs. The SP3 process allows you to update as many SYS:\PUBLIC directories as you need to.

If any GroupWise administrator on your network uses an older version of the GroupWise 5.2 Admin DLLs to administer GroupWise after SP3 has been applied anywhere in your GroupWise system, an incorrect DST date could be stored in the domain database. This will cause the incorrect appointments and time stamps if those times were established by GroupWise 4.x prior to migration.

  • Recover the Primary Domain Database. You should perform a database recover on the primary domain database of your GroupWise system if:

    • You originally installed GroupWise 5.x with a GWADMN32.DLL file dated earlier than April 15, 1998, and then you migrated your GroupWise 4.x primary domain to GroupWise 5.x with that version of the GroupWise snap-in.

    • Some GroupWise 4.x components are still present in the system.

    If you have already applied SP3, you can perform a database recover to ensure that the correct DST information is used by the 4.x-level components in your system. Note that you can perform a database recover while the database is in use.

Performing a Database Recovery. Here are the steps to perform the recovery.

  1. From NetWare Administrator, select the 5.x primary domain object. Click Tools | GroupWise Utilities | System Maintenance to display the GroupWise System Maintenance dialog box shown in Figure 2.

    Figure 2: The GroupWise System Maintenance dialog box.

  2. Click Recover Database | Run to display the Database Path dialog box (see Figure 3).

    Figure 3: Database Path entry box.

    If the path to the primary domain database is incorrect, enter the correct path, then click OK to begin the recovery process. Or, if the path to the primary domain database is correct, click OK to begin the recovery process.

    When the recovery is complete, the dialog box shown in Figure 4 is displayed.

    Figure 4: "Database recovery completed" message.

  3. Click OK and then Close to close the recovery tool dialog box.

After you have completed the database recovery, check to see if appointment times have been corrected. If some appointments are still off by one hour, you may need to use the GroupWise Appointment Time Adjuster to correct the remaining problems.

Recheck the Appointment Times

After you have applied SP3 and recovered the domain database, ask your users to recheck the appointment times that have been made between groups A and B, as defined earlier.

If the appointment times are correctly synchronized between Group A and Group B, prior corrective steps were successful and DST problems are resolved.

If there are still differences in the appointment times between Group A and Group B in spite of prior corrective steps, or if you know the differences are caused because DST was turned off in GroupWise 4.1 before migration, you can do one of two things: use the GroupWise Appointment Time Adjuster or check and reschedule appointments.

Using the GroupWise Appointment Time Adjuster. The GroupWise Appointment Time Adjuster utility (ADJAPPT.EXE) is designed to help you resolve appointment times that may be off by one hour because of an incorrect DST end date setting or because of a migration from GroupWise 4.1. There are two versions of the utility, one designed to run against GroupWise 4.1 post offices where the appointments originated before the migration, and one designed to run against GroupWise 5.x post offices (those in Group A) where the appointments originated before the migration.

For more information about obtaining and using the GroupWise 4.x and 5.x Appointment Time Adjusters, see the online GroupWise and Daylight Saving Time administration guide.

Checking and Rescheduling Appointments. If the number of incorrect appointments is minimal, or if you cannot obtain or run the GroupWise Time Adjuster utility to help you resolve appointment times, you may ask your Group A users to check and reschedule the appointments they sent before the migration.

You should have the users check and reschedule all appointments scheduled for recipients residing in any time zone. This procedure will not cause any down time for your system.

  • If you are using GroupWise 5.2: If the rescheduling is done after SP3 is applied and the primary domain database is recovered, the appointments should be correctly synchronized.

  • If you are using GroupWise 5.5: The appointments should be correctly synchronized.

When to Correct DST Problems

If you have to change the Daylight Saving Time settings of a domain or a post office, the start times for appointments created before the DST reset will shift forward or backward by one hour (or the amount of change in DST). This happens if appointments are created while GroupWise DST settings are incorrect and are later corrected.

If you use GroupWise 5.2, remember that depending on the GroupWise 5.2 client being used, different DST records are accessed. A GroupWise client can use either an absolute setting for appointment calculation, or it can use a formula-based setting for appointment calculation. This inconsistency among 5.2 clients may cause some clients to experience problems while others do not. If you fix a problem at the wrong time, it may appear to introduce more problems than it solves.

Use the following scenarios as a basic guide to help you determine when to correct DST problems.

Scenario 1

If all users on a GroupWise system are currently using incorrect DST settings, you should wait to correct the problem until after DST observance has ended. In North America, for example, this would occur during the first week of November.

In this situation, all users will continue to be wrong together, so no problems should be noticed until after DST ends. At that time, you can adjust the DST settings and all new appointments will be created properly.

Note: GroupWise Remote does not use the domain database for time zone information, so appointment times that were created with the Remote client will continue to be incorrectly synchronized with real time until after you make the DST adjustments to the GroupWise domains and post offices.

Scenario 2

If the domains or post offices of some users have correct DST settings and the domains and post offices of other users do not use the correct DST settings, the situation is more difficult. Some new appointments will be incorrect until DST settings are adjusted, but older appointments will appear to shift if you make the DST corrections.

In this situation, the choice of the best strategy depends on how many users will be affected. If 10 percent or more of the users are using incorrect DST settings, changing the settings as soon as possible may be the best way to resolve the problem. After making the change, you may have to use the GroupWise Appointment Adjuster to fix the older appointments that have shifted.

Conclusion

This AppNote has summarized the main issues surrounding Daylight Saving Time and GroupWise. For more information, see the online GroupWise and Daylight Saving Time administration guide at:

http://www.novell.com/products/groupwise/administration/gwdaylt0.html

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates