[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.

On Wed, 2010-06-02 at 14:59 +0200, Bill Allombert wrote:
> On Tue, Jun 01, 2010 at 10:47:18AM +0900, Charles Plessy wrote:
> > RFC 822 dates use only two digits for the years, but Debian changelogs
> > described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch
> > replaces the RFC 822 by its latest evolution, RFC 5322, that specifies a date
> > format suitable for Debian changelogs.
> > ---
> >  policy.sgml |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/policy.sgml b/policy.sgml
> > index d16df70..7e2365e 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -1610,7 +1610,7 @@
> >  	</p>
> >  
> >  	<p>
> > -	  The <var>date</var> must be in RFC822 format<footnote>
> > +	  The <var>date</var> must be in RFC5322 format<footnote>
> >  	      This is generated by <tt>date -R</tt>.
> >  	  </footnote>; it must include the time zone specified
> >  	  numerically, with the time zone name or abbreviation
> > -- 
> >
> What is the diffrence between RFC5322 and RFC2822 time format ?
> RFC 5322 was only released in 2008, so the standard that packages
> actually follow is clearly RFC2822.
> I would prefer if we keep a reference to RFC2822 because is is
> more well known than RFC5322
> The 'date' utility denotes this format under 'RFC 2822':
> The option is named --rfc-2822 and the documentation list
> RFC 2822.

I disagree: We should migrate our documentation to use the newest
version of such standards when the standards body concerned updates
them.  In this case RFC2822 is superseded by RFC5322, and so we should
reference the newer version.  The new standard has been out for two
years, and we haven't done it already!?

This makes it a bug for things to be incompatible with the newer
standard, which overall makes the adoption of the newer standard easier.

I'd be surprised if it actually has an effect on Debian in this case,
which is even more of a reason to use the newer standard.  Moving
everyone to the new standard is often difficult (how many times do we
still hear of RFC822 being referred to?) and we should help grease the
wheels as much as possible.

Filing a bug against coreutils for the date option naming is probably a
good idea too - it is hopefully trivial for them to allow the option to
also be referenced as --rfc-5322.  They appear to have made this change
in the past, because the --rfc-822 option also works, though it is


andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
                   Be cautious in your daily affairs.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: