Bug?

[Bill Vermillion]

On Thu, Apr 01, 2004 at 12:29:53AM -0500, Jay R. Ashworth thus spoke:
> On Wed, Mar 31, 2004 at 11:49:07PM -0500, GCC Consulting wrote:
> > I am writing a field from 6,ymd format to 8,mdy/ format...the date is 040329 and
> > comes out as 04/03/29...while the year COULD be 1929, should filePro convert it?
> > Courtney Karl Seith
> > ------------------------------------------------
> > If I am reading the date correctly, it translates to March 29, 2004.
> > 
> > If this is the case, the 8,mdy/ is reading the date correctly at posted, April
> > 3, 2029.
> > 
> > This is not a bug, fp expects the values to be in the proper sequence.
> > 
> > You need to use a mid statement to translate the values into the proper sequence
> > 
> > Cko(4)=mid(7,"3","4"){mid(7,"1","2") 

> That's not *MY* understanding of how system date edit fields work,
> dude.

> Assignments between date edit fields of different types are supposed to
> Just Work, swapping elements as necessary, and consulting PFCMARK
> (presumably) to fill in extra digits if going from a y to a yy edit.

> Such has always been my experience, and I have utilized YYMD fields on
> occasion as copies of "human readable" dates, for doing things like
> multiple-field edits with descending date before fP knew how (convert
> to YYMD, then subtract from 99999999, and index.  Forget whether I
> stole that from Jeff or Ron... :-).  All *I* ever remember having to do
> was assign.

On a sales call tracking for a customer years ago - machine was
an AT&T 3B2/310 - I needed to sort the calls to the client so the
last call would come up on top. I created a 5 digit field
and then subtracted todays date from 12/31/2099.

That machine replaced a Radio Shack 16 - on a very very long
conversion I did during the Christmas week of 1985.  When we
converted from the 3B2/310 it was during the Christmas break
of 1990 - and we had one piece of HW shipped wrong that arrived
about 1PM on 12/24 and the vendor closed at noon that day.

Then I ran into the fixed ulimit of 1MB that was compiled into
the SysV.2, and had to build a new 'login' that set ulimit higher
than then called the real login, renamed to login2.

Things are so much nicer now.  Today's bugs seem more like a
may-fly in comparison to the ones in the earlier machines.

Bill

-- 
Bill Vermillion - bv @ wjv . com