Time differs between calendar view and appointment document

HCL Domino Domino Forum
1

I reported this issue quite some time back in the 8.0 forum, but the problem continues in 8.5.1 so I thought I’d post here to see if anyone has any ideas.

We have one user whose calendar is acting extremely strange.

He has many meetings scheduled throughout the week. Each of the meeting documents has the correct meeting times recorded in the fields (according to the document properties).

Here’s the funny thing…

In the document properties, the appointment dates/times are all correct

When you open the document, the dates/times appear correctly

In the “Day at a Glance” all of the meeting/appointment details are correct

If you specify “Show Summary” in the claendar view, the appointment times appear correctly

It’s ONLY when you specify “Show Timeslots” that the issue appears. EVERY appointment is scheduled for 5 hours prior to the actual time (e.g. a 9AM appt appears to start at 4AM)

I have even tried to run some formula agents on the user’s client to reproduce what should be displayed in the view, and they always display the correct date/time.

There must be something unique about this user’s operating system, because the appointments appear fine when I open them from other users’ clients (both Windows XP and Vista).

I simply cannot find out what the difference is.

Can anyone tell me what differentiates the different calendar views?

I figure that if I can determine what formula is causing the misrepresentation of the appointment time, that’ll lead me to the spot where the client is mis-configured.

I have compared the user’s NOTES.INI to other’s that work fine.

I have reviewed the registry to determine if there’s anything there that may be causing the issue.

I’ve checked the user’s preferences to ensure the region and DST settings are all set properly.

I have pretty well run out of options, and really would appreciate it if someone could suggest an alternative place for me to look.

Thank very much in advance!

T.

2

Subject: Questions

Is the user’s location document set to observe the OS Time Zone settings? What OS are they using?

Is the user using the 8.5.1 mail template? In the Day/Week views time slots should be on automatically

3

Subject: More information…

Sorry, I should have posted that additional information in my original post…

The user is using MS Vista, but I have tested calendar access using both XP and Vista clients (all OK with those other clients).

We have tried setting the OS to observe/not observe DST, as well as different settings in the Location document. We have also created entirely new Location documents in case of corruption.

The server and client are both on 8.5.1, as is the mail template. You’re right, the time slots are displayed by default. It just so happens that that is the ONLY area where this issue presents itself! If I display summary information instead, the issue disappears.

I have even tried removing the ($Calendar) view from the mail database and performing a design replace (didn’t work).

Any help would be most appreciated!

T.

4

Subject: Try these steps and let me know the results

Set the user’s location document to observe the OS settings completely, save the location documentClose Notes

Now edit your system date/time and time zone to reflect the correct settings, even if they look correct, just change it 1 minute and then back to what it should be, and change the daylight savings checkbox to off then back on.

Load Notes back up and go to the Calendar let me know if that solves the issue.

5

Subject: We seemed to have solved the issue…

Thanks very much for your responses Dave!

Prior to reading your response, we decided to play with the registry settings. We copied settings from a working client over to the “bad” client, and everything seemed to play nicely after that!

The settings we reproduced were located in:

HKLM\System\CurrentControlSet\Control\TimeZoneInformation

I’m not sure which of the settings were the ones which screwed us up, but we’re just happy to have resolved the issue.

Hopefully, this helps someone else out in the same predicament one day.

Cheers!

T.

6

Subject: Glad to hear

This should hopefully be fixed in Fixpack 1 coming out for 8.5.1 although the SPR is still open. The SPR for this issue is DCON7VRMTR