Nash!Com Workspace
Database Catalog
Command Line Tools
Sync & Import Solutions
rDNS Replacement
Extended Mail Log
Special DB Fixup
Daylight Savings Fixup
Trace/Lowercase Conversion Extension
Run Special Tasks
Demo & Evaluation

Nash!Com Daylight Savings Fixup Solution

Time and Date functions are an essential part of the Notes infrastructure and are used e.g. for Calendaring and Scheduling and Replication. Specially for replication a very flexible timezone and daylight savings aware Timedate data type was needed. The Timedate data type was introduced in Version 1.0 of Notes and supports powerful functions like @Adjust on all levels of the product.

Although this concept already contained support for Timezones and Daylight Savings there are still problems with configuration of international environments in R4/R5 environment. The following short article will describe some background about Timedates and the problems that specially occur migrating to R5 where the Timezone and Daylight saving settings are synchronized with the operating system on most platforms.

Windows and most other operating systems support Timezones and Daylight Saving information.
But in contrast to Notes in most operating systems this information is not part of the time and date data type.

Windows Date & Time Implementation

The Windows Date & Time Implementation uses a data type called DATE and is implemented using 8-byte floating-point number. Days are represented by whole number increments starting with 30 December 1899, midnight as time zero. Hour values are expressed as the absolute value of the fractional part of the number.


Date and timeRepresentation
30 December 1899, midnight0.00
1 January 1900, midnight2.00
4 January 1900, midnight5.00
4 January 1900, 6 A.M.5.25
4 January 1900, noon 5.505.50
4 January 1900, 9 P.M.5.875

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];

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 */

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.


  • Windows 2000 in Timezone CET (Central Europe GMT+1),
    Daylight Savings activated (means GMT+2).

  • Notes R4 Client Timezone CET (GMT+1),
    DST not enabled (GMT+1)

Let us assume Windows shows 30.7.2001, 10:00 CEDT Central European Daylight Time (this is in fact 10:00 GMT+2)

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
  • Notes R5 Client Timezone CET (GMT+1),
    DST enabled because it is synchronized with the operating system (GMT+2 --> CEDT like the operating system on our first machine)
When we take the Timedate stored on the R4 Client we get the following results.

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?
  • Make sure you have consistent settings on operating systems and Notes Client/Servers.
First you need to make sure that Notes Clients and Servers have exactly the same Timezone and DST settings as your operating system. In R5 environments this is normally done automatically because by default Notes R5 synchronizes it's timezone and DST settings with operating systems. For other operating systems like UNIX you still need to apply the right DST settings in the server document and specify the DSTLaw parameter in the Notes.ini.
  • Correct the data in your Notes document that have not been stored with the right Client/Server settings.
Some companies had to disable those settings in R5 because this was in conflict with their current date stored in the wrong internal format as shown above. There is a undocumented not fully supported way to run Notes Clients in the old style independent from operating system. The notes.ini setting which is needed for this is UseNotesTimeZone=1 and will allow to work independent form the operating system time settings. This notes.ini solution is not recommended and Lotus regards it as a temporary work-around.

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
  1. Reading it without DST enabled
  2. Writing it back with DST flag enabled.
This will correct the time as needed.

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