Understanding GroupWise Daylight Saving Time issues.

Figuring out GroupWise Time issues.

Appointment times off by one hour
Appointment times wrong in client.
Mail delivery time incorrect.
Time on POA wrong.
Figuring out GroupWise Time issues.

There are many factors that affect the time in GroupWise, namely:

1. The Time zone definition that the server running the POA is using.
2. The Time zone definition of the timezone assigned to the domain in GroupWise.
3. The Time zone definition of the timezone assigned to the Post Office in GroupWise.
4. The Time zone definition on the timezone workstation where the client is running.

A major difference in GroupWise 6 and 6.5 from earlier versions is that they use the local workstation time for displaying appointments rather than the POA time. When an GW6.x client creates an appointment it knows what time zone the local workstation is set to and the Daylight Savings Time status and bias. It uses this to calculate the UTC time and it is the UTC time that is stored in the GroupWise database. When a receiving 6.x client reads the appointment from the database it uses the stored UTC time and adds it's local GMT offset and DST status and bias to calculate the time of the appointment in the current location.

From this it is possible to see that if the client applies the incorrect calculation to derive the UTC or on the UTC then the appointment times will be shown incorrectly.

Using the above diagram it is possible to derive the UTC and where the problem may be occurring. Imagine that an appointment is sent using the GroupWise 6.0 client for 1pm on October 27 2003. The client knows that it is currently in the GMT +1 time zone and it also knows that the date is in a time where DST is active.

UTC= Appointment time (1pm)- DST Bias(0 hours as it should be on October 27 2003) - GMT Offset (1 hour) =12pm.

If a GroupWise 6 client reads this whose time zone information is wrong (lets say that it thinks DST is disabled in November as inthe diagram above) then the client will peform the following operation on the appointment.

Appointment time= Stored UTC (12pm) + GMT Offset (1 hour) + DST Bias (1 hour) = 2pm.

So, an appointment sent for 1pm in the afternoon may display as 2pm on a different workstation when all clients are the same version.

Using the same understanding it is possible to work out problems where the Post Office time zone definition is incorrect.

Imagine a GroupWise 5.5 client sending an appointment for 1pm on October 27 2003 again, but this time the time zone on the Post Office incorrectly has summertime ending on the last Sunday in November (as in the diagram above). The UTC that gets stored in the database is as follows:

UTC= Appointment time (1pm) -DST Bias(1 hour as the PO time zone is incorrect and 5.5 clients get the time for the POA) - GMT Offset (1 hour) = 11am.

If a GroupWise 6 client reads this appointment whose workstation time zone is correct then the following calculation will occur.

Appointment time= Stored UTC (11am) + GMT Offset (1 hour) + DST Bias (0 hours, correctly) = 12pm.

As another example imagine that all the clients in the Post Office are 6.x clients, however, when they send a mail between each other the Delivered time shows one hour early. The Delivered timestamp is generated by the POA rather than the client as it is the POA that is performing the action. Examing the timezone information on a workstation shows that the timezone definition is correct so UTC is generated as follows:

UTC = Sent time(10am) - DST Bias (1 hour) - GMT Offset (1 hour)= 8am.

When the POA needs to update the delivered time it performs the following calculation on the Sent time:

Delivered time = Stored UTC(8am) + GMT Offset (1 hour) + DST Bias (unknown at this point) = 9am. This is one hour too early, so we can then assume that the DST Bias has moved too early. Checking the Time zone definition should show that the timezone has been defined incorrectly.

When checking where the problem lies it is often best to start at the bottom and work up, ie, start with the server time zone, followed by the Post Office time zone and finally the workstation time zone. It is not only important to check which time zone is assigned to each of these but also to check the definition of each assigned time zone.

Check TID 10057376 for a possible problem with server time zone definitions.
When checking the Post Office time zone open the properties of the PO object in ConsoleOne and look which time zone is assigned. Then go to Tools | GroupWise System Operations | Time Zones and Edit this time zone. Check that the offset from GMT and the DST start, end and biases are correct. Do the same for the workstations.

If there are only one or two users in a Post Office with the problem, most likely it is a workstation time issue. Check for current Windows DST patches and verify that Automatically adjust clock for daylight saving changes is actually checked. (In Windows, right click on the clock in the system tray | adjust date/time | time zone tab).

If all users are having a problem then it is more likely to be a Post Office problem. The domain time zone becomes important when WebAccess is being used so this needs to be checked also. CheckTID 10076257for a possible WebAccess time zone issue.
Correcting the problem for appointments already sent can be difficult. In the case where the Post Office time zone is wrong and a mix of 5.5 and 6.x clients have been used then some appointments will be stored with the correct UTC and some will have the wrong UTC and administrators are going to need to know which user has been sending appointments and from which version of the client. Sometimes it is better to live with the problem for a short time rather than to try and repair all the bad appointments, however, there is aAppointment Time Adjusterthat can be run against single users or against an entire PO that can help to correct appointment times.

Formerly known as TID# 10081255