Conference noted::hackers_v1

    I don't know, but wait until Jan 1, 2000 for similar fun.  Ought to be
    good!
    
    -Mike

I was  supporting  a  UNIVAC 9060E for many years and one day (Jan 2, 1978 I
think)  it  kept crashing during system boots. There was no reason given for
the  crash,  the  machine  just  kept  halting  at  the same location. After
checking the source code, I found that the last system boot date was kept in
a somewhat munged fashion in a 2 byte field...  the date flip to 1978 caused
the  location  to go negative, and subsequent packed operations on this data
just  stripped  the  UNI's  gears..  I  patched  the  boot  to  and  out the
(propogated)  sign  bits  and  it came up fine... 

Every UNIVAC  site  had  this problem happen to them; try to imagine what it
must have been like for them to get their customer service reps to figure it
out over the New years holidays...

RE .1:

If you think *that's* fun, wait until 1-Mar-2000, and there *isn't*
a leap year.  I bet they won't even be done fixing all the new year's
bugs when it goes off.
				/AHM

    	I have heard of the same problem on an IBM system, and think
    it is very likely true, but after PS/8, TSS-8 and TOPS-10 I do not
    think we should make too much of an issue about it....
    
    	Dave

re: .3

	2000 is a leap year!

Steve

    2000 is not a leap year.  Years divisible by 4 but not 100 are leap
    years.  2000 does not qualify.
    
    tom_p

    Then again, OS8 and COS300/310 had a base year stored with a 3 bit
    offset.  The base year had a hardcoded value of 1972.  I was supporting
    the 8s in 1979 when everyone became aware of the potential problem.
    
    In 1979, our attitude was "if it has the word 'dec' on it, we will
    support you".  We had lots of fun tracking down all of the COS300/310
    systems to give them the patch to change the base year.  A lot of
    the people i talked with said "Okay fine now, the date is okay
    for the next 8 years, what am I going to do in 1988?" 
                                   
    tim...
    ps, Rick Murphy, it's good to see you admit PDP 8 knowledge.

      Jan 2000               Feb 2000               Mar 2000
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
                   1          1  2  3  4  5             1  2  3  4
 2  3  4  5  6  7  8    6  7  8  9 10 11 12    5  6  7  8  9 10 11
 9 10 11 12 13 14 15   13 14 15 16 17 18 19   12 13 14 15 16 17 18
16 17 18 19 20 21 22   20 21 22 23 24 25 26   19 20 21 22 23 24 25
23 24 25 26 27 28 29   27 28 29               26 27 28 29 30 31
30 31

    Wrong company - it was DEC, and the TOPS-10 operating system.  That
    was the DATE75 problem alluded to earlier.  The date field in TOPS-10
    pre 1975 was stored in a 12 bit field, days since some random date
    in the early 1960's.   There was a big scramble in 1974 to get TOPS-10
    to handle dates past ??'th January 1975.  ( TOPS-10 has an 18 bit
    date field now, I think, but I doubt that it will be around to see
    that turn over.  )
    
    								/alan

    re .7
    You forgot the last part.  The year does qualify if it is divisible
    by 400.
    

    Re: Leap year
    
    According to Common Lisp: The Language, leap years are yeers divisible
    by four, except those divisible by 100, except those divisible by
    400. Hence, I think 2000 is a leap year.
    
    DFW

Subj:	Stanley hacks a user with a Rabinowitzian SPR response
Subj:	a sledgehammer...
Subj:	AND 2000 is the last year of the 20th Century not the first of the 21st
Subj:	Fixed in next century
Subj:	SPR response on leaping ahead to the year 2000
Subj:	Calendar SPR
Subj:	try again.....
Subject: My SPR answer (for your review)
                   ******DEC INTERNAL USE ONLY******            
 
SPR NUMBER:                  11-60903

ANSWER CATEGORY:             UE
MAINTENANCE HOURS:           1
DUPLICATE PROBLEM:           N
DUPLICATE SPR NUMBER(S):     
 
OPERATING SYSTEM:            VAX/VMS             
O.S. VERSION:                V3.2
PRODUCT:                     VAX/VMS
PRODUCT VERSION:             V3.2
COMPONENT:                   Run-Time Library
SUB-COMPONENT:               LIB$ routines
 
DATE ANSWERED:               13-Oct-1983

MAINTAINER:                  Stanley Rabinowitz
 
ATTACHMENT:                  N

PUBLICATION INSTRUCTIONS:    N

SPR PROBLEM ABSTRACT:        User claims year 2000 should not be a leap year.

TITLE:                       -
PUBLICATIONS:                -
ADDITIONAL O.S. VERSIONS:
ADDITIONAL PRODUCT VERSIONS:
COMPONENT SEQUENCE NUMBER:   
SUPERSEDES:                  
TYPE OF ARTICLE:             

                            ANSWER CATEGORIES

CG=1=CORRECTION GIVEN       RS=5=RESTRICTION              SG=9=SUGGESTION
FN=2=FIXED IN NEXT RELEASE  CS=6=CUSTOMER SUPPORTED       IQ=10=INQUIRY
DE=3=DOCUMENTATION ERROR    NR=7=NON-REPRODUCIBLE         HW=11=HARDWARE
UE=4=USER ERROR             II=8=INSUFFICIENT INFORMATION

                            TYPE OF ARTICLE

F=OPTIONAL FEATURE PATCH    N=NOTE
M=MANDATORY PATCH           R=RESTRICTION

                         FOR MAINTENANCE USE





                     ******END OF DEC USE ONLY******
                            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 affect
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  364  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).   It's
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

    I've read this before, but had forgotten its elegance and beauty.
    Thanks, Scott, for posting it!
    
    BTW, does anyone know if this actually got past SPR administration
    and to the customer?  Did the customer have any response?
    
    Burns
    

If you're desperately in need of a calendar program, feel free
to copy REX::USER$A:[DECUSC.TOOLS]CALEND.C

Note, however, that it does not properly handle the French and Russian
revolutionary calendars.

    Leave it to Stan!
    
    I stand corrected.  Who can argue with that???
    
    tom_p

Re .10:

Even though the UDT (Universal Date/Time) format dates are stored with
18 bits for the date and 18 bites for the time in Tops-10, file creation
and access dates in file RIBs are stored in 15 bit fields, not 18 bits.
The 15 bit fields (which used to be 12 bits) use the "1-Jan-64" format.
				/AHM

    I just finished reading a short article in the March 17 issue of
    FORTUNE.  It seems Lotus 1-2-3 (and Symphony) think that 1900 was
    a leap year.  Also the editors of the user's magazine say that the
    latest version thinks that 2000 is not (a leap year).  The writer
    of the article checked with his version of the program and found
    that it correctly recognizes the year 2000 as a leap year.

re .14

Yes, it really went out!  I'm the RTL supervisor so I have all the old
RTL SPRs clogging up my file cabinet and 11-60903 is really in there,
yellow paper and all.  I just looked in the file and unfortunately,
there was no reply card and I couldn't find anything from the customer
following up on it.  Guess we'll never know what the customer thought. 

(Of course, it's only been 2 1/2 years.  Maybe I could give the customer 
a call just to see if he's satisfied with our service!)

This thing really should be framed -- it seems a shame to keep such a
masterpiece hidden in a dusty file cabinet!  I wonder if there's anyone 
in the company who hasn't heard about Stan's SPR?

Associated Press Tue 15-JUL-1986 19:31                           Sprint Error

   Computers Not Adjusted; Customers Billed On Standard Time

   WASHINGTON (AP) - Someone at the Sprint long-distance company
forgot to spring forward when Daylight Savings Time started on April
27 so customers got overcharged or underbilled for some calls, a
spokesman said Tuesday.
   The error was fixed May 15 and bills will be adjusted, the
spokesman said.
   It is the second time this year a program error caused Sprint
customers to get wrong bills. Earlier, because of a software error,
10 of Sprint's 58 switches were not billing calls.
   In that case, Sprint used backup records to send late bills to
customers, and most of them paid up, the spokesman said.
   According to Communications Week, a trade publication, until the
new problem was detected, customers who called between 5 p.m. and 6
p.m. and between 11 p.m. and midnight were charged higher rates,
while those who called between 8 a.m. and 9 a.m. paid lower
overnight rates.
   ``Somebody thought somebody else had done it,'' said Sprint
spokesman Sydney E. Courson, referring to the failure to reset the
computer's clock.
   Courson said he did not know the value of the incorrect billing,
but said customers are being notified with bill stuffers and charges
will be recalculated and adjustments made shortly.

    Re: Stan's SPR Response...
    
    As a customer until quite recently, I had the pleasure of attending
    the '86 Spring DECUS in Dallas.  There had been a great brouhaha
    at one of the sessions in New Orleans (I was there for that too)
    the year before about 2000 being a leap year.  Someone, (and I regret
    that I do not remember who) read Stan's response at the VAX Magic
    session, much to the delight of the audience...
    

Re .0

This did happen to a Mass based company to remain anonymous.

The month September has 9 letters in its name (more than any other
month!).  When September 1st rolled along systems in Europe began
crashing only to be followed by systems in the U.S.  I don't know
if it happened to other companies, but it's possible!

David

RE: .21

I read Stan's response at the Spring '86 DECUS VAX Magic Session.  The idea
occurred to me when I listened to the tape of the Spring '85 Magic Session
(where I told the PROBE.COM war story), and there was a big argument over
whether 2000 will be a leap year.  Stan's SPR answer came to mind immediately.

--PSW