Re: Y2K

From: Byron C. Darrah <>
Date: Fri, 9 Oct 1998 13:35:19 -0700 (PDT)
Message-Id: <>

> Date: Fri, 9 Oct 1998 16:04:10 -0400 (EDT)
> From: "Randall S. Winchester" <>
> Sender:
> cc:
> On Fri, 9 Oct 1998, Byron C. Darrah wrote:
> : Hmm. I don't think Y2K compliance can be guranteed for any software that
> : uses system date/time related functions and either has to be compiled or
> : uses shared libraries.
> You must state that first the OS and hardware you are running the product on
> must be Y2K compliant. This is common practice, and should be obvious.

Fair enough.

> : If Y2K compliance for hypermail is desired, then there should probably be
> : some statically-linked binary images available somewhere, which have been
> : tested on the desired platforms.
> This is not nessesary, provided you do the above. The world is not going to
> abandon shared libraries over Y2K. You just put the responsibility of
> verifying the shared libraries on their providers.

Well, a *lot* of commercial software seems to be statically linked, and I can understand why.

> : If that is not desirable, then perhaps the installation procedures could
> : include some way of checking the environment or the hypermail binary (after
> : it is built) for compliance.
> I do not think this is reasonable. Running tests on a Y2K compliant machine
> at the various "Y2K important dates" and verifying date fields will make
> most people happy. I do not know all the hoops to be "legaly certified" but
> for free/shareware software it will not happen.

Hmm, I can understand why Kent, myself, or you might not have it as a high priority. But if someone else, to whom the issue is more important, is willing to write a script or something that puts hypermail through a couple of simple tests, how would that be unreasonable?

(I just thought I'd put this stuff out for discussion. I hope my ignorance isn't too offensive to anyone.)

--Byron Darrah

> : Thread index shows messages starting Mon 15 Jun 1970, ending Thu 24 Sep
> : 1970. Bummer; it not only thinks 2000 is 1970, but it thinks 2001 is also.
> Thanks!
> : line 200 of file.c adding 1900 to now->tm_year
> : CENTURY defined as 1900, and BASEYEAR defined as 1970 in hypermail.h
> : functions "splitshortdate" and "convtoshortdate" in date.c manipulate
> : things in terms of 2 digit years, not a good sign. The latter is designed
> : to handle an explicit string with the 4 digit year and chop it to 2 digits.
> Ugly two digit years, this will not do!
> So b4 will either be a week late or there will be b5 real real soon.
> Note: This needs to be fixed asap.
> Randall
Received on Fri 09 Oct 1998 10:38:50 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT