Path: utzoo!attcan!uunet!snorkelwacker!apple!brutus.cs.uiuc.edu!psuvax1!news From: flee@shire.cs.psu.edu (Felix Lee) Newsgroups: news.software.b Subject: Our friend, the GMT date. Message-ID: <1989Dec3.210413.27043@psuvax1.cs.psu.edu> Date: 3 Dec 89 21:04:13 GMT References: <4364@helios.ee.lbl.gov> <14810@well.UUCP> Sender: news@psuvax1.cs.psu.edu Organization: Penn State University Computer Science Lines: 30 Jef Poskanzer wrote: > Interesting. When the (second) test article left helios, it said: > Date: 3 Dec 89 08:58:48 -0800 > But I'm getting reports that when it arrived on other sites it said: > Date: 3 Dec 89 16:58:48 GMT B news (2.11.19 and earlier) will parse the Date: header and rewrite it as GMT. If it can't parse the date, it will rewrite it as GMT anyway, which is where "31 Dec 69 23:59:59 GMT" comes from. If you don't like rewriting the date, it's a simple fix to header.c; but even if *you* don't rewrite it, your neighbors probably will. TMNN does rewrite the date, but won't put "31 Dec 69". Instead, it will put the current date, and add an "X-Unparsable-Date" field. RFC-1036 says that the Date field shouldn't change, but doesn't say whether you can change the representation while keeping the value. It doesn't say what to do with unparsable dates either; it is legal to reject such articles out of hand. TMNN will also rewrite the Expires date, which is probably the wrong thing to do with relative dates ("Expires: 3 days"). Relative dates aren't blessed by the RFC, but are understood by getdate(). The RFC defines a valid date as something 822-ish that getdate will accept, an operational definition not terribly useful to un-Unix news implementers. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee