HP3000-L Archives

October 1996, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
MR JOHN P BURKE <[log in to unmask]>
Reply To:
MR JOHN P BURKE <[log in to unmask]>
Date:
Mon, 28 Oct 1996 10:21:29 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
-- [ From: John P. Burke * EMC.Ver #2.5.1 ] --

I'm flattered so many people read my article in the October issue of The
3000 News/Wire: "The Adager Date Functions: Rx for the Year 2000
Problem". Adager has come up with a wonderful enhancement to a product
that is already an indispensible tool at many sites.

But, as many people have pointed out, the article contains an error. I
had hoped few people would pick up on this and I could just correct it
in the November issue. Silly me. I guess the surest way to find out if
something is being read is to have an error in it. Anyway, following is
the copy that will appear in the November issue of The 3000 News/Wire.

Regards,
John Burke


A Clarification on October's ADAGER "DATES" Test Drive

For the October Test Drive, I created a test database and populated it
with five years worth of dates in a variety of formats. Part of my plan
was to see how ADAGER handled dates intended to be from the years 2000
and 2001 but only having two digits describing the year (for example, I
intended the ascii string 000229 to represent 02/29/2000). At this point
I had a serious case of brain lock and forgot that when I replied NO to
using a cutoff value, ADAGER would assume 000229 was 02/29/1900 and not
02/29/2000! I then compounded the goof by concluding that ADAGER's
flagging of 000229 as invalid was justified because 2000 is not a leap
year. Bzzzzzzz. The year 2000 IS a leap year but the year 1900 is not
(see net.digest this month for information on when a year is a leap year
). ADAGER works just fine (when I went back and revisited my tests, this
time using a cutoff value, ADAGER correctly accepted 000229 as valid).
It was the tester, in a hurry trying to wrap things up before going on
vacation, who was in error. My apologies to the folks in Sun Valley,
Idaho.

ATOM RSS1 RSS2