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.