Hallo,
meinst du diesen Artikel?
Nummer: 7003354
Some geographic regions observe Daylight Savings Time (DST). This means that twice a year (normally in March and October) the clocks have to be changed, gaining or losing an hour.
Due to the current observance of differing DST settings within users' configurations, some users are experiencing issues where Notes appointments and events are appearing off by an hour. This document describes the settings that should be implemented to address these issues.
If you work in a region that uses Daylight Savings Time, you should enable both Notes and your operating system's Daylight Savings Time settings. Certain regions do not observe DST, and if you work in one of these regions you should NOT have Daylight Savings Time observed in either Notes or your operating system.
Note: The settings are relevant to both Notes clients and servers.
Notes needs to know when the Daylight Savings Time should be handled. Prior to the Notes releases 4.5.4 and 4.6.1 (including all localized versions), Notes used the North American rule to enable the change to Daylight Savings Time, which is:
- the first Sunday of April and the last Sunday of October
Starting with 4.5.4 and 4.6.1, the International English version will by default use the most common European rule, which is:
- the last Sunday of March and the last Sunday of October
You still have the opportunity to change the hardcoded rule and define your own settings by specifying the DSTLAW variable in the NOTES.INI. For North American versions, DSTLAW=4 1 1 10 -1 1 , whereas the International versions use DSTLAW=3 -1 1 10 -1 1.
Here is an excerpt from the Notes/Domino 4.5.4 and 4.6.1 fix lists:
SPR# GMEN3NKFE5 - Changed the Daylight Savings Time default for International English Notes/Domino to be from March through October as is true in the GMT time zone. The Time Zone Setup dialog still reads April-October; however, and this problem will be fixed in a future release.
Here is an excerpt from the Notes/Domino 4.5.6 and 4.6.2 fix lists:
SPR# DSCZ3PS5MM - Remove the text, April-October, in the Time Zone Setup dialog checkbox, "Observe Daylight Savings Time."
When a user receives a Calendar entry in her/his mail file, the message subject contains the times when that person is invited. These times have been computed with the time zone the meeting chairperson observes. However, there is no mention of this person's "daylight savings time" configuration.
The visualization of a Date/Time field (TIMEDATE) is adapted to the Notes client time zone settings. As well, the visualization of a calendar entry is adapted to the invitee's settings to facilitate comprehension.
The TIMEDATE field in Notes is affected by both the time zone setting and the Daylight Savings Time setting. If two users in the same time zone don't have the same Daylight Savings Time setting, the subject line automatically generated in the invitation will be different by 1 hour in the summer and the same in the winter.
All documents that have been created with a Daylight Savings Time setting won't be automatically changed if that Notes client's settings are changed. In this case, all entries will show an incorrect value in the summer. Moreover, there is no way to easily change the setting in a TIMEDATE field. A workaround is to convert the TIMEDATE field into text, change this setting inside the string and convert it back to a TIMEDATE field.
Here is an extract of the Notes C API user's guide:
The Notes TIMEDATE structure consists of two long words that encode the time, the date, the time zone, and the Daylight Savings Time settings that were in effect when the structure was initialized. The Notes TIMEDATE structure is designed to be accessed exclusively through the time and date subroutines defined in misc.h. This structure is subject to change; the description here is provided for debugging purposes.
The first DWORD, Innards[0], contains the number of hundredths of seconds since midnight, Greenwich mean time. If only the date is important, not the time, this field may be set to ALLDAY.
The date and the time zone and Daylight Savings Time settings are encoded in Innards[1]. The 24 low-order bits contain the Julian Day, the number of days since January 1, 4713 BC. Note that this is NOT the same as the Julian calendar! The Julian Day was originally devised as an aid to astronomers. Since only days are counted, weeks, months, and years are ignored in calculations. The Julian Day is defined to begin at noon; for simplicity, Notes assumes that the day begins at midnight. The high-order byte, bits 31-24, encodes the time zone and Daylight Savings Time information. The high-order bit, bit 31 (0x80000000), is set if Daylight Savings Time is observed. Bit 30 (0x40000000) is set if the time zone is east of Greenwich mean time. Bits 27-24 contain the number of hours difference between the time zone and Greenwich mean time, and bits 29-28 contain the number of 15-minute intervals in the difference.
For example, 2:49:04 P. M., Eastern Standard Time, December 10, 1996 would be stored as:
Innards[0]: 0x006CDCC0 19 hours, 49 minutes, 4 seconds GMT
Innards[1]: 0x852563FC DST observed, zone +5, Julian Day 2,450,428
If the time zone were set for Bombay, India, where Daylight Savings Time is not observed, 2:49:04 P. M., December 10, 1996 would be stored as:
Innards[0]: 0x0032B864 9 hours, 19 minutes, 4 seconds GMT
Innards[1]: 0x652563FC No DST, zone 5 1/2 hours east of GMT, Julian Day 2,450,428
A user receives a calendar invitation. This invitee's Notes client adapts the schedule depending on the chairperson's settings. If both users, chairperson and invitee, have the same time zone and Daylight Savings Time settings, there will be no misinterpretation of the schedule. On the contrary, nothing will tell the invitee what the chairperson's settings are.
In all Notes 4.x versions, changing to a location which is not in the same time zone as the location you are changing from modifies the operating system time and adds the difference between the two time zones. Closing the Notes client does not change the operating system time back to what it was before the Notes client opening. This behavior helps mobile clients to adapt their working environment to local time to allow them to manipulate calendar entries without making any effort.
Starting 4.5.5 and 4.6.2, operating system time zone and time settings can not be modified when the Notes client location is changed to a new location where the time zone is different under Windows 32-bit environment. This can be done by adding the NOTES.INI variable Allow_OS_Time_Zone_Change=0.
Here is an excerpt from the Notes/Domino 4.5.5 and 4.6.2 fix lists:
SPR# SMUN322PSN - On Windows 95 and Windows NT, adjust the operating system timezone as well as the operating system clock when a user selects a new timezone in the active Location document.
Viele Grüße
Sophia
