SECTION 2 -- MISCELLANEOUS DATE QUESTIONS
<> 02.001 Is 2000 A.D. a leap year?
[I cannot see any way to improve on this posting taken verbatim from
comp.databases.ingres. --Roy Hann]
From agnew@gems.vcu.edu
Date: 18 Oct 96 16:11:02 -0400
From: Brainwave Surfer
Newsgroups: comp.databases.ingres
Subject: Year 2000 is a LEAP Year!!
well, guys about 2000 as the leap or non-leap year, here is the
DEFNINITIVE response.... Jim
X-News: gems comp.os.vms:29785
From: Paul S Winalski
Subject:Re: RE: YEAR 2000
Date: 24 Feb 1996 05:31:01 GMT
Message-ID:<4gm7ql$kkv@zk2nws.zko.dec.com>
OBRIEN wrote:
>
>
>On this issue, there is a wonderful SPR which I have seen copies on DECUS
>collections and Compuserve .. and possibly was posted here at some time. I
>cannot remember the references, but have kept my own local copy, gleaned from
>one of these sources, and which I always give a copy of to anyone who argues
>that 2000 is not a leap year.
You refer to the famous SPR response drafted by Stan Rabinowitz in response
to an SPR filed against VMS V3.2 claiming that the LIB$DAY RTL function was
incorrect in treating the year 2000 as a leap year. Here, published for
the first time anywhere, is the unexpurgated first draft of the SPR
response. DEC SPR Administration made him remove the bit at the end
about WWV and atomic clocks, and the reference to VMS V4.0. I had the
honor of being the technical reviewer for the answer.
It is probably the only response to a software bug report ever to mention
Sosigines, Regiomontanus, and the Council of Trent.
--PSW
=========================================================================
D I G I T A L
SPR ANSWER FORM
SPR NO. 11-60903
SYSTEM VERSION PRODUCT VERSION COMPONENT
SOFTWARE: VAX/VMS V3.2 VAX/VMS V3.2 Run-Time Library
PROBLEM:
The LIB$DAY Run-Time Library service "incorrectly" assumes the year
2000 is a leap year.
RESPONSE:
Thank you for your forward-looking SPR.
Various system services, such as SYS$ASCTIM assume that the year 2000
will be a leap year. Although one can never be sure of what will
happen at some future time, there is strong historical precedent for
presuming that the present Gregorian calendar will still be in effect
by the year 2000. Since we also hope that VMS will still be around by
then, we have chosen to adhere to these precedents.
The purpose of a calendar is to reckon time in advance, to show how
many days have to elapse until a certain event takes place in the
future, such as the harvest or the release of VMS V4. The earliest
calendars, naturally, were crude and tended to be based upon the
seasons or the lunar cycle.
The calendar of the Assyrians, for example, was based upon the phases
of the moon. They knew that a lunation (the time from one full moon
to the next) was 29 1/2 days long, so their lunar year had a duration
of 354 days. This fell short of the solar year by about 11 days.
(The exact time for the solar year is approximately 365 days, 5 hours,
48 minutes, and 46 seconds.) After 3 years, such a lunar calendar
would be off by a whole month, so the Assyrians added an extra month
from time to time to keep their calendar in synchronization with the
seasons.
The best approximation that was possible in antiquity was a 19-year
period, with 7 of these 19 years having 13 months (leap months). This
scheme was adopted as the basis for the religious calendar used by the
Jews. (The Arabs also used this calendar until Mohammed forbade
shifting from 12 months to 13 months.)
When Rome emerged as a world power, the difficulties of making a
calendar were well known, but the Romans complicated their lives
because of their superstition that even numbers were unlucky. Hence
their months were 29 or 31 days long, with the exception of February,
which had 28 days. Every second year, the Roman calendar included an
extra month called Mercedonius of 22 or 23 days to keep up with the
solar year.
Even this algorithm was very poor, so that in 45 BC, Caesar, advised
by the astronomer Sosigenes, ordered a sweeping reform. By imperial
decree, one year was made 445 days long to bring the calendar back in
step with the seasons. The new calendar, similar to the one we now
use was called the Julian calendar (named after Julius Caesar). Its
months were 30 or 31 days in length and every fourth year was made a
leap year (having 366 days). Caesar also decreed that the year would
start with the first of January, not the vernal equinox in late March.
Caesar's year was 11 1/2 minutes short of the calculations recommended
by Sosigenes and eventually the date of the vernal equinox began to
drift. Roger Bacon became alarmed and sent a note to Pope Clement IV,
who apparently was not impressed. Pope Sixtus IV later became
convinced that another reform was needed and called the German
astronomer, Regiomontanus, to Rome to advise him. Unfortunately,
Regiomontanus died of the plague shortly thereafter and the plans died
as well.
In 1545, the Council of Trent authorized Pope Gregory XIII to reform
the calendar once more. Most of the mathematical work was done by
Father Christopher Clavius, S.J. The immediate correction that was
adopted was that Thursday, October 4, 1582 was to be the last day of
the Julian calendar. The next day was Friday, with the date of
October 15. For long range accuracy, a formula suggested by the
Vatican librarian Aloysius Giglio was adopted. It said that every
fourth year is a leap year except for century years that are not
divisible by 400. Thus 1700, 1800 and 1900 would not be leap years,
but 2000 would be a leap year since 2000 is divisible by 400. This
rule eliminates 3 leap years every 4 centuries, making the calendar
sufficiently correct for most ordinary purposes. This calendar is
known as the Gregorian calendar and is the one that we now use today.
(It is interesting to note that in 1582, all the Protestant princes
ignored the papal decree and so many countries continued to use the
Julian calendar until either 1698 or 1752. In Russia, it needed the
revolution to introduce the Gregorian calendar in 1918.)
This explains why VMS chooses to treat the year 2000 as a leap year.
Despite the great accuracy of the Gregorian calendar, it still falls
behind very slightly every few years. If you are very concerned about
this problem, we suggest that you tune in short wave radio station
WWV, which broadcasts official time signals for use in the United
States. About once every 3 years, they declare a leap second at which
time you should be careful to adjust your system clock. If you have
trouble picking up their signals, we suggest you purchase an atomic
clock (not manufactured by Digital and not a VAX option at this time).
END OF SPR RESPONSE
<> 02.002 Are there any Y2K (Year 2000) problems with Ingres?
The OpenIngres DATE data type handles dates in the range 01-jan-1582
(the beginning of the Gregorian era) to 31-dec-2382 with a resolution
of 1 second. Dates represented using the DATE datatype will therefore
be unaffected by the turn of the century.
However there may be problems displaying dates or entering dates in
Ingres applications if the application programmer has used date
templates that omit the century (eg: d"03FEB01" or d"02/03/01").
As a temporary solution OpenIngres supports an environment variable
called II_DATE_CENTURY_BOUNDARY that controls the interpretation of
the year part by the front-end. If this environment variable is set
to 50 (say), an input value of less than 50 will be interpreted as
being in the 21st century, and a value of more than 50 will be
interpreted as being in the 20th century. For example, an input of
03 will be interpreted as 2003, and an input of 99 will be interpreted
as 1999. Note that this strictly a display issue; dates are stored
correctly in the OpenIngres database.
While not a Y2K problem, note that SELECT dbmsinfo('_bintim') returns
the number of seconds since January 1st, 1970. Many programmers
convert this to a 4 byte integer and use it as a compact time stamp.
In mid-2035 this will roll over and cease to work.