Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!uunet!world!geoff
From: geoff@world.std.com (Geoff Collyer)
Newsgroups: news.software.b
Subject: Re: The anomolous handling of bad dates in cnews.
Message-ID: <1991May23.024533.9731@world.std.com>
Date: 23 May 91 02:45:33 GMT
References: <1991Apr25.181041.6023@mp.cs.niu.edu>
	<1991Apr25.223301.27280@world.std.com>
	<1991May16.211311.3544@eua.ericsson.se>
Organization: Software Tool & Die Netnews Research Center
Lines: 28

Per Hedeland:
> In article ... (Geoff Collyer) writes:
> >No, inews and friends parse any existing Date: header contents and
> >rewrite them in RFC 1036 (as modified by RFC 1123) notation.  An
> >unparsable date will cause the article to be bounced.
> 
> I don't think this is correct; ...
...
> Getabsdate will not print anything on stdout for an "invalid" date,
> which causes $timet to be any empty string, and ctime to produce the
> well-known date "Thu Jan  1 00:00:00 1970" - which is indeed "too old"
> for most news setups.

Whoops, I was confused about error reporting conventions; fixed.

> I really hope that inews in the future will not reject articles with bad
> dates, but fix up the date instead (just setting the posting date if the
> given one is unparsable seems quite reasonable to me) - IMHO, this *is*
> the place to try to "repair" headers, and it already does insert the
> missing spaces that are so impossible for relaynews to provide.

As I said above, inews rewrites the date, if it can understand the date
at all, into canonical form.  If it can't understand the date using a
fairly tolerant parser (getabsdate for Date: and getdate [for now] for
Expires:), I don't think substituting the current date is a great
idea.
-- 
Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff