My original message is:
"Hello managers!
> I'm trying to make sure that I have all of the year 2000 compliant
> versions
> of shareware packages (such as lsof, top, kermit, perl, etc.), and I'm
> having trouble in my search.
>
> I've found that the April 1998 version of lsof included y2k info, and I'm
> seeing into downloading it. I've read top's home page, and I can't find
> anything that mentions y2k. I've tried repeatedly this morning to log onto
> kermit's home page, but I can't seem to get connected. I don't know what
> the
> URL for the University of Alaska's utilities (ua_uerf, ua_date, uaio, etc
> -
> great package!) is, and I've got to find that before I can figure out if
> it's y2k or not. Finally, does anyone know if uudecode, uuencode,
> uudeview,
> and uuenview are part of the DU package or are they shareware? If they're
> shareware, then where is the home page for them?
>
> Any help on the above mentioned is appreciated.
>
> Thank you!"
>
>From Tom Webster I received this:
> Perl - From the perl FAQ on www.perl.org:
>
> ----- snip ----- snip ----- snip ----- snip ----- snip -----
>
> Does Perl have a year 2000 problem?
>
> Not unless you use Perl to create one. The date and time functions
> supplied
> with perl (gmtime and localtime) supply adequate information to determine
> the
> year well beyond 2000 (2038 is when trouble strikes). The year returned by
> these
> functions when used in an array context is the year minus 1900. For years
> between
> 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the
> year 2000
> problem simply do not treat the year as a 2-digit number. It isn't.
>
> When gmtime and localtime are used in a scalar context they return a
> timestamp
> string that contains a fully-expanded year. For example, $timestamp =
> gmtime sets
> $timestamp to ``Tue Nov 13 01:00:00 2001''. There's no year 2000 problem
> here.
>
> ----- snip ----- snip ----- snip ----- snip ----- snip -----
>
> Uudecode, uuencode - Are part of DU's uucp package, and are thus covered
> under
> the DU4.0d certification blanket.
>
You should also take a look at
http://www-th.phys.rug.nl/~schut/gnulist.html
which covers the majority of the GNU software.
>From Alan Davis I got this:
> ftp://raven.alaska.edu/pub/randy/
>
> There is a general freeware site of pointers to these
> and other tools at :
>
> http://www.digital.com/info/misc/pub-domain-osf1.txt.html
>
>
Regarding the "top" utility, I wrote to William LeFebvre directly and asked
him about it. Here's what he sent to me:
It is in the 3.5beta release. Here is the statement:
Top and the Year 2000
The software package top will not be affected by years numbering
between 2000 and 2037. No portion of the top code stores dates on
disk. All date processing in top is performed with functions from the
Unix C library and Unix kernel. The specific functions are: time(2)
and ctime(3S). These functions deal exclusively with conventional
Unix time values (number of seconds since Midnight January 1, 1970
GMT) and produce strings with a 4-digit year. At no point in the code
for top are the last two digits used to represent a year.
Top and the Year 2038
In the year 2038 top will fail to represent the time of day correctly
on 32-bit Unix operating systems. This is due to a limitation in the
way Unix represents time. Top will only work on systems whose kernel
call "time" and C library call "ctime" have been adjusted to represent
time with a value greater than 32 bits. The exact date and time of
this failure is 3:14:08 January 19, 2038 GMT. Note that this failure
will only affect the display of the current time in the output from
top.
THERE IS ABSOLUTELY NO WARRANTY PROVIDED WITH THIS SOFTWARE.
Please see the contents of the file "DISCLAIMER" for further
information.
And finally, regarding uuenview and uudeview, I wrote to Frank Pilhofer, and
here's what he replied:
Hi,
since neither UUDeview nor UUEnview handle any date values, they are
y2k compliant. I honestly don't understand all the hype this y2k prob-
lem is causing. There can only be a problem if date differences are
computed.
Frank
Thanks to everyone who replied!
-Stephen Spalding
Received on Mon Oct 05 1998 - 14:16:00 NZDT