# What Is Wrong With Year 1700?

2008 is a leap year again. The Gregorian calendar, the current standard calendar in most of the world, adds a 29th day to February in 97 years out of every 400, a closer approximation than once every four years. This is implemented by making every year divisible by 4 a leap year unless that year is divisible by 100. If it is divisible by 100 it can only be a leap year if that year is also divisible by 400.

So, in the last millennium, 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not. In this millennium, 2100, 2200, 2300, 2500, 2600, 2700, 2900 and 3000 will not be leap years, but 2400 and 2800 will be. You can find numerous examples in almost every programming language of how to determine if a year is a leap year or not.

In LotusScript as well as with @Formula you can “adjust” a given date to another date depending on the parameters you use. So the easiest method to determine a leap year is to set the date to March, 1st of the given year and “substract” one day. If the resulting date is Feb., 29th, the year is a leap year.

Here is my @Formula

```_date:=[01.03.1700];
@Prompt([Ok];"Last Day";@Text( @Day( @Adjust( _date; 0;0;-1;0;0;0 ) ) ) )
```

I expected a 28 in the message box, but it prompted 29 ! Oups …

I tried the same using LotusScript and the NotesDateTime class

```Sub Click(Source As Button)
Set dt = New NotesDateTime( Datenumber( 1700 ,3, 1) )
Msgbox dt.Localtime
End Sub
```

Guess what it returns. 29.02.1700 ! Another oups …

Seems that IBM / Lotus uses another calender than the Gregorian calendar. No surprise is that ðŸ™‚

You might want to try the next piece of code and watch what happens …

```Sub Click(Source As Button)
Set dt = New NotesDateTime( Datenumber( 1700 ,3, 1) )