Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!bcm!tmc.edu!sob
From: sob@tmc.edu (Stan Barber)
Newsgroups: news.software.b
Subject: Re: CNews - now a pedantic software! : -(
Message-ID: <5077@gazette.bcm.tmc.edu>
Date: 8 Apr 91 06:15:07 GMT
References: <1991Apr02.183535.13886@buster.stafford.tx.us> <1991Apr3.001125.2057@zoo.toronto.edu> <3313@crdos1.crd.ge.COM>
Sender: usenet@bcm.tmc.edu
Organization: Baylor College of Medicine, Houston, TX
Lines: 60
Nntp-Posting-Host: tmc.edu

In article <3313@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  I'm going to make a suggestion here, and let whoever agrees with my
>vision of the future run with it. In a few years we will have a date
>rollover. While a date containing, for instance, 91 and 04, is obviously
>parsable into day of the month and year, that won't be true shortly.
>
>  Consider a data spec as follows:
>	month	three letters, capitalised
>	day	one or two digit number 1..31
>	year	four digit number
>	time	three groups of two digit numbers, colon separated
>	TZ	three uppercase characters or a one or two digit
>		number starting with + or -.
>
>  This is almost like the fields in RFC1036 (as I remember, I have to
>get a new copy), except the year. It has the advantage that every field
>may be differentiated from every other, and therefore order is no longer
>important. This seems like a wonderful idea, given that we're talking
>about a missing space.

Actually, RFC1123 has already modified the rules to deal with the coming
year 2000. Since RFC1123 modified RFC822 and since RFC1036 sez that 
dates are supposed to be formated like RFC822 sez, it follows that dates
should look like this in news (and mail). Here is the section on the new
date format from RFC1123.

      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5

         The syntax for the date is hereby changed to:

            date = 1*2DIGIT month 2*4DIGIT

         All mail software SHOULD use 4-digit years in dates, to ease
         the transition to the next century.

         There is a strong trend towards the use of numeric timezone
         indicators, and implementations SHOULD use numeric timezones
         instead of timezone names.  However, all implementations MUST
         accept either notation.  If timezone names are used, they MUST
         be exactly as defined in RFC-822.

         The military time zones are specified incorrectly in RFC-822:
         they count the wrong way from UT (the signs are reversed).  As
         a result, military time zones in RFC-822 headers carry no
         information.

         Finally, note that there is a typo in the definition of "zone"
         in the syntax summary of appendix D; the correct definition
         occurs in Section 3 of RFC-822.

The mods to Bnews to support are simple. Look in funcs2.c for the arpadate
function.




-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: rutgers!bcm!sob             and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine