Re: LYNX-DEV Year 2000 Compliance

[T.E.Dickey]

> Nelson Henry Eric wrote:
> 
> > > source files for any indication of Y2K compliance, and if they can see it
> > 
> > Thanks to Tom and Bela, we now know it is not compliant.
> 
> I'm not sure I would say that.
I would not either - I would only go so far as to say that we've inspected
it, corrected some potential problems & found nothing serious.  (But like
all programs, it may still have problems that we have not diagnosed).  I
noted this in the README.
 
> The two "actual problems" I reported related to Lynx's handling of data
> provided to it by older programs which have Y2K problems.  Like any web
> browser, Lynx must deal with all sorts of external programs: HTTP & FTP
> servers, the output of HTML generators, local handlers for various MIME
> types, etc.  My suggestions were intended to make Lynx more robust when
> dealing with Y2K problems in *those* programs.
I understood that - thanks.
 
> I did not find any places where Lynx's own internal activity would have
> caused a Y2K problem.  Also, I didn't notice where Tom (you mean Thomas
> Dickey?) found anything beyond those two.  (He did seem to question the
> mktime() implementation, but I'm pretty sure that he'll find, on closer
> examination, that it does *not* have a Y2K problem.  tm_year, in struct
> tm, is *defined* as "years since 1900".  In 2003 it will have the value
> 103; this is normal, expected, and does not cause a problem.  struct tm
> fields are not intended for unprocessed display.)
I did check PDM's mktime.c (by writing a simple test, stepping through several
years back/ahead 1 hour per step) just to verify the algorithm, since the
handling of leap year was not apparent (yes, I'm aware that there are compact
algorithms for it, but I've not memorized them ;-).  It's ok, so I made no
further mention.
 
> >Bela<
> 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey