The URL that Dale Miller provided contains the text
<begin extract>
One possibility is that the certificates Azure relied on allotted
years consisting of only 365 days, rather than the 366 days that are
needed once every four years to account for leap years. If that error
affected Azure certificates, the cloud platform may have shut down as
systems were unable to confirm they were connected to other trusted
nodes.
</end extract>
Some few years after Gregory XIII's introduction of AD 1582 many
people are still using the Roman/Julian definition of a leap year
instead of the Gregorian one.
In fact the Gregorian calendar introduced a second-order correction.
Years are of two kinds, centurial and non-centurial. Every fourth
centurial year is a leap year, and every fourth non-centurial year is
a leap year. All other years are common, non-leap ones.
Thus:
leapchk: procedure(year) returns(aligned bit) reorder ;
/* returns true for leap years, false for non-leap years */
declare year signed binary fixed(31,0) nonassignable parameter ;
declare leap aligned bit ;
declare (H0 value(0), H4 value(4), H100 value(100), H400 value(400))
signed binary fixed(15,0), mod builtin ;
leap = (mod(year,H4) = H0) ;
if leap then
do ;
leap = (mod(year,H100) ¬= H0) ;
if leap then ;
else leap = (mod(year,H400) = H0)) ;
end ;
return(leap) ;
end leapchk ;
Code that embodies (or uses via subroutine call) the Julian definition
of a leap year is fatally flawed.
"Grappling with the idiocies of time management" is best left to
coloro che sanno.
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
