|
Nash!Com Daylight Savings Fixup Solution
The Operating System has properties to switch between Summer and Winter time and also maintains timezones but there is no support for storing timezone and specially DST information in a Windows Time/Date. This is a problem specially when working in different timezones and with different daylight saving settings because time is always stored in the local format. UNIX Date & Time Implementation The UNIX Time & Date Implementation uses a different approach. UNIX uses the standard ANSI C time_t and tm structure for conversion similar to Notes. typedef long time_t; This is a 32bit signed Integer storing the number of seconds since 1.1.1970 midnight! struct tm { int tm_sec; /* seconds after the minute - [0,59] */ int tm_min; /* minutes after the hour - [0,59] */ int tm_hour; /* hours since midnight - [0,23] */ int tm_mday; /* day of the month - [1,31] */ int tm_mon; /* months since January - [0,11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday - [0,6] */ int tm_yday; /* days since January 1 - [0,365] */ int tm_isdst; /* daylight savings time flag */ }; In contrast to Notes it does not store timezone information and has only a limited support for DST. Notes Date & Time Implementation Notes Time & Date Implementation uses the TIMEDATE data type an internal 2 times 32 bit storage that contains date, time, timezone and daylight saving information typedef struct tagTIMEDATE { DWORD Innards[2]; } TIMEDATE; All TIMEDATEs are internally stored in GMT also called Coordinated Universal Time (UTC) and the timezone and daylight saving settings when storing this information are also saved into this data type. There are powerful API routines to work with TIMEDATES. Lotus Script and Lotus formula language is based on those routines. The expanded form of a TIMEDATE looks like this typedef struct { int year; /* 1-32767 */ int month; /* 1-12 */ int day; /* 1-31 */ int weekday; /* 1-7, Sunday is 1 */ int hour; /* 0-23 */ int minute; /* 0-59 */ int second; /* 0-59 */ int hundredth; /* 0-99 */ int dst; /* FALSE or TRUE */ int zone; /* -11 to +11 */ TIMEDATE GM; } TIME; Because of this very strong implementation Date & Time in Notes are always timezone and daylight savings aware! Windows & UNIX Date & Time is not aware of these details and Notes has to convert it accordingly. Because of this Notes and OS need to have exact the same Timezone and also Daylight Saving settings! In R5 this is simple because platforms like Windows and Mac do support the synchronization of those settings by default. In R4 you have to make sure to have the right DST and DSTLaw settings specially in international versions which are used in many different locations and may not contain the correct settings for your country. How does it work? Notes takes the local time from the operating system and converts it into internal GMT / UTC format applying the current timezone and daylight saving settings. Internal operations like comparing of time Timedates for example for replication always use the internal GMT stored time which is universal around the world. Only for displaying it again for example in the Client, on the server console or converting it into a string the current timezone and DST settings will be applied to the Timedate and is displayed accordingly. This might cause time differences when the Client has not the exact same settings than the operating system. If you switch your operating system to Summer time Notes also needs to know about this to interpret the time it gets from the operating system accordingly. The following example shows why it is important to have exactly the same settings on Clients and Servers. Example:
Notes takes this time and converts it into internal GMT storage by assuming CET without DST (which is in fact GMT+1). Internally this time is stored as 9:00 GMT. This will "display" correctly in all environments having the same DST settings but in fact this is internally converted into a wrong time. Let us now assume we are looking into this Timedate from a different Notes Client with properly setup DST settings to see which problems we might run into
Internal stored Timedate is 30.07.2001, 9:00 GMT (including info it was stored in CET) The Notes Client converts the time it according to it's current time settings (CET + DST = CEDT / GMT+2) for display. Surprisingly the resulting Time is 11:00 CEDT instead of 10:00 CEDT! So why does this happen an when does it happen? It always happens when the Notes Client has different settings than the operating system. As long you keep the same settings and times on both sides you are always save. But as soon you run your operating system in a different realm than your Notes Client you run into problems when leaving your "island" where you agreed on those settings. Specially in international organizations and communicating with other companies may cause problems for example in C&S applications. So what can be done to avoid these problems?
Modifying these documents sounds easy. And in some environments where you exactly know that everyone had the same settings on Clients/Servers it might work just to correct the time by one hour. But this solution might not lead to the desired results in most cases because you have not the full set conversion functions in Lotus Script you have in the Notes C-API. The best solution is to read the Timedate with the settings it has been stored and write it back after applying the right settings to the Timedate. This will keep the time and just stores it with the right Timezone and DST settings. But how can we find out if a Timedate needs to be adjusted? Every timezone has it's own rules when Daylight Savings is activated and turned back. We can now read the Timezone from the Timedate and match it with the Daylight Savings rules we have for this timezone. If the Timedate is in the Daylight Savings interval and the DST setting is not set the internal representation needs to be adjusted by
Unfortunately these modifications cannot be done in Lotus Script because not all API calls have equivalents in the Script Classes. There might be a way to work around this for normal dates but there is no way to manipulate time ranges and time lists. Nash!Com Daylight Savings Solutions Because of these problems and limitations Nash!Com wrote a migration tool for converting/fixing Timedates, Timedate-Ranges and Timedate-Lists. The command-line tool does help you to convert Timedates that have been stored with the incorrect DST settings described above. Due to the complexity of this topic and the high impact correcting those settings in all databases and documents in your organization we do only provide this solution with at least 2 days of on-site consulting. In those two days we would scan some of your servers, provide detailed information about all needed settings (clients and servers) and discuss details about your scan results. Short Overview of nshdst Highlights - scanning all databases on a server - reporting summary and detailed information about documents and fields which need to be converted - checking for encrypted documents - avoids to break signatures when timedates are not parts of the signed data - configuration that allows to fix subsets of documents e.g. by formula and date - features to ensure each replica is just converted once - resuming of analysis and fixup process after shutting down the servertask - unread marks remain unchanged in most szenaios - supports profile documents - works for international organizations with multiple timezones |
