[news.software.b] Another 'unparsable date' error

news@devon.UUCP (Usenet News Manager) (02/08/88)

Software:  B-news 2.11, patchlevel 14
Hardware:  TRS-80 Model 16, Xenix 3.2

Several months ago, my expire/inews started showing errors like:

	expire: Unparsable date "31 Dec 69 23:59:59 GMT"

It was explained (by Rick Adams, I believe) that this was the result
of a date routine returning a -1; hence the conversion to the 1-second-
before-the-epoch date.  However, over the last several days, I have
been seeing:

	expire: Unparsable date "6 Feb 06 06:28:15 GMT"

It's always the same date and time.  Certainly the sixth of February of
nineteen-ought-six is *well* before the 'epoch'.  And, no, I haven't
calculated what return value would cause that date.  :-)

Explanation anyone?

- paul

wisner@fenchurch.MIT.EDU (Bill Wisner) (02/09/88)

In article <677@devon.UUCP> news@devon.UUCP (Usenet News Manager) writes:
>Software:  B-news 2.11, patchlevel 14
>Hardware:  TRS-80 Model 16, Xenix 3.2

>	expire: Unparsable date "6 Feb 06 06:28:15 GMT"

It's not isolated; I've seen identical behavior on a PC AT clone
running Microport and news at patchlevel 12.

..bill

msb@sq.uucp (Mark Brader) (02/12/88)

> >	expire: Unparsable date "6 Feb 06 06:28:15 GMT"

Assuming the date to be in the 21st century, this gives a time value
of 1139207295, or 0x43E6EC7F.  (Found by playing with values for about
1 minute; I figured it was quicker than writing a program.)

However, that number sure doesn't suggest anything to me.
Hope it helps somebody.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
	"I'm a little worried about the bug-eater," she said.  "We're embedded
	in bugs, have you noticed?"		-- Niven, "The Integral Trees"

geoff@desint.UUCP (Geoff Kuenning) (02/17/88)

In article <1988Feb11.184413.18950@sq.uucp> msb@sq.UUCP (Mark Brader) writes:

> > >	expire: Unparsable date "6 Feb 06 06:28:15 GMT"
> 
> Assuming the date to be in the 21st century, this gives a time value
> of 1139207295, or 0x43E6EC7F.  (Found by playing with values for about
> 1 minute; I figured it was quicker than writing a program.)

Whenever I see a date in the range of "00-09", I think 20th, not 21st,
century.  The range of a 31-bit number is about 68 years;  the base is
1970.  So a maximal negative number produces a date in the early 1900's.
I'd suspect 0x7FFFFFFF, though I didn't take the time to try it out.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff

msb@sq.uucp (Mark Brader) (02/20/88)

> > > >	expire: Unparsable date "6 Feb 06 06:28:15 GMT"
> > 
> > Assuming the date to be in the 21st century, this gives a time value
> > of 1139207295, or 0x43E6EC7F.

> Whenever I see a date in the range of "00-09", I think 20th, not 21st,
> century.  I'd suspect 0x7FFFFFFF ...

He means 0x80000000, of course.  Nope.  My arithmetic this time may be a
little suspect, but ctime() seems to work on negative values on this machine,
except for printing the day of the week as garbage unless it's Friday,
["%" never returns a negative result, right? :-)] and that gives me the
above date as being -2016552705, i.e. -0x78322701, i.e. 0x87CDD8FF assuming
2's complement 32-bit numeration.  Which doesn't seem to help much either.
Oh well.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
	"I'm a little worried about the bug-eater," she said.  "We're embedded
	in bugs, have you noticed?"		-- Niven, "The Integral Trees"

asp@COS.COM (Andrew S. Partan) (03/01/88)

I have been getting the following unparsable dates:
	31 Dec 69 23:59:59 GMT
	6 Feb 06 06:28:15 GMT
	<2553@gryphon.CTS.COM> GMT

How can I find out what articles these dates are coming from??  I would
like to delete the offending articles.

I tried running fgrep on every article that I have on my system, and
also looked in ~news/history.  No luck.

Anybody have any ideas?

Thanks,
	--asp (Andrew Partan @ Corporation for Open Systems)
	-- asp@cos.com or asp%cos.com@uunet.uu.net
	-- {uunet, sundc, decuac, hqda-ai, hadron}!cos!asp
	ASN.1 Object Identifier: "{joint-iso-ccitt mhs(6) group(6) 157}"
DISCLAIMER:  Opinions expressed are not necessarily those of the
Corporation for Open Systems, its members, or any standards body.