Xref: utzoo news.sysadmin:2419 news.admin:5818
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: news.sysadmin,news.admin
Subject: Re: question on bad unparsable dates
Message-ID: <7008@cbmvax.UUCP>
Date: 29 May 89 19:34:22 GMT
References: <185@icdi10.UUCP> <730@dtscp1.UUCP> <455@focsys.UUCP>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 39

In article <455@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes:
> In article <730@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes:
> >>May 27 00:29	local	Unparsable date "31 Dec 69 23:59:59 GMT"
> >Now for nearly a month, I have been getting mail that says this.
> >Where do these come from?  Does the SysAdmin for the site producing
> >these know about them?
> 
> I ran expire with verbose set to 3 and waded through >3 Meg of output
> looking for the possible source of this annoying error. The files that
> expire seemed to flag as the source of this error looked okay to me.

Let's suggest that the problem is with the date parsing routine defining
an error return value of "-1" to mean that the date couldn't be parsed.
Now if '31 Dec 69 23:59:59 GMT' happens to be the date that when parsed
and evaluated returns the binary date value of '-1' then the code that
called the getdate routine will give a confused error message, stating
'parse error' when really it means 'date outside of era'.

[ i just peeked at getdate - it actually does a range check, so two
  strikes - invalid dates get normalized to 31 Dec 69... slimey coding
  practice to combine both range checking and parsing and only return
  one error code eh? ]

Secondly, one might suggest that such dates are generated when software
accepts the value of getdate, without checking for error returns.  When
translated back to ascii form, you get this magic day in 1969.  Instances
of '01 Jan 70 00:00:00' (date '0') would be similarly suspect, but
generate no error messages.

The simple fix is to comment out the code producing the error message.
Part of installing/customizing news for a particular installation is
generally disposing of the multitude of "don't really care" error messages.

Obviously, the sources of the defective dates should be tracked down and
eliminated, but it's a big world and a little problem.
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)