D3 works like:

leapyear = (int(year/400) = year/400) or ((int(year/100) # year/100) and
(int(year/4) = year/4))

because there's 365.24 days in a year, you add 1 every 4 years, adjust back
once every 100 and ajust once again every 400.

400 and 800 should be leap years, and 200 and 600 should not be. IMO

Mark


"frosty" <frostyj (AT) bogus (DOT) tld> wrote

Interesting sidethought, I always prefer writing:

mod(year,400)=0 in preference to int(year/400)=year/400... it just seems
more compact. Similarly mod(year,100)>0 instead of int(year/100) #
year/100.

So your statement becomes

leapyear=((mod(year,400)=0) or ((mod(year/100)>0) and (mod(year,4)=0))

Guess I'm just bored on a Saturday morning.

Regards
Simon


"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

From an esthetics point of view you're absolutely correct. It's more
human-readable.

But under the hood, int(x/y) is faster.

In fact, it's faster to say not(mod(year/100)) than mod(year/100) > 0, but
not so much as to make a difference unless you're doing it a bazillion
times.

Cheers!

Mark


"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote

In all the discussion about dates in previous centuries, has anyone
considered the effect when the 11 days were dropped from the calendar
in 1752 (in Britain)? This, coupled with the fact that my old AP
system considers all x00 years to be leap years, required a fascinating
algorithm when I needed to handle dates on a local history website
which I organise.

Regards

Malcolm Bull

The actual definition is:
1.. Every year divisible by 4 is a leap year.
2.. But every year divisible by 100 is NOT a leap year
3.. Unless the year is also divisible by 400, then it is still a leap
year.
So, 100, 200, 300, 500, 600, 700, 900,1000, etc are not leap years, but 400
& 800 are because they are divisible by 400.

Even I understand this, but will probably forget it next week. :-)

Bill

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

We had discussions like this here in CDP and at Pick Systems back when
it was important. Off the cuff I'd say it doesn't matter what a
modern application does with dates anytime prior to 1900 or after
2034, unless it requires forward planning (mortgages) or needs to be
historically accurate (museums). I'm a stickler for accuracy with
things like this, but this simply doesn't apply to 99.x% of the
software in our market today. Anyone who has an application where
this would be important had plenty of chance to make their concerns
known in 1999. (Reminds me of the HHGTTG, beware of the leper
segment.)

If you have an application which requires historical accuracy for
years 200, 600, etc, then petition the vendor for a fix for their next
release, but I don't think you'll get it. In 1999 I did some research
on the subject. It's fascinating how proper calculation of dates is
also dependent on the location of an event, not just the time, since
some countries have changed calendars a few times, and some only
within the last 100 years. It might be best to write your own code
which calculates the correct date for the correct calendar for the
specific location of interest. That said, I know there are websites
with these calculations and there might even be a Web Service setup
somewhere to do exactly what I'm describing. If I thought I could
make a couple bucks on it I might do this myself... oh well.

T